options.setProperty(org.apache.axis2.transport.http.HTTPConstants.SO_TIMEOUT,new

Integer(480000));

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CONNECTION_TIMEOUT, new Integer(480000));

The best way to describe what IoC is about, and what benefits it can provide, is to look at a simple example. The following JDBCDataManger class is used to manage our application's accessing of the database. This application is currently using raw JDBC for persistence. To access the persistence store via JDBC, the JDBCDataManger will need a DataSource object. The standard approach would be to hard code this DataSource object into the class, like this:

public class JDBCDataManger {
  public void accessData() {
    DataSource dataSource = new DataSource();
    //access data
    ...
}

Given that JDBCDataManger is handling all data access for our application, hard coding the DataSource isn't that bad, but we may want to further abstract the DataSource, perhaps getting it via some system-wide property object:

public class JDBCDataManger {
  public void accessData() {
    DataSource dataSource = 
      ApplciationResources.getDataSource();
}

In either case, the JDBCDataManger has to fetch the DataSource itself.

IoC takes a different approach — with IoC, the JDBCDataManger would declare its need for a DataSource and have one provided to it by an IoC framework. This means that the component would no longer need to know how to get the dependency, resulting in cleaner, more focused, and more flexible code.

IoC Frameworks

The ideas behind IoC aren't especially new; in fact, many have remarked that IoC is nothing but a new acronym for the older Dependency Inversion Principle (PDF file). What is new is the interest in IoC, and the large number of frameworks being actively developed to aid the use of IoC.

IoC frameworks are the facilitators for the IoC pattern — think of a framework's job as being the glue for connecting the components in an IoC system. While the general principle of IoC is fairly straightforward, there are several distinct implementations evident in the frameworks. The developers of PicoContainer originally defined the three types of IoC, in order to differentiate their approach from the other frameworks around at the time. At first, these types were simply called Types 1,2, and 3, but in Martin Fowler's recent article, "Inversion of Control Containers and the Dependency Injection Pattern," he coined some more informative terms for these three types, which we will use below.

In the rest of the article, we'll look briefly at Avalon, and in more depth at the two most popular IoC frameworks, Spring and PicoContainer, and the types of IoC they provide.

Interface Injection (Type 1)

With Interface Injection IoC, components implement specific interfaces provided by their containers in order to be configured. Let's look at a refactor of our JDBCDataManager that uses the Avalon framework:

import org.apache.avalon.framework.*;

  public class JDBCDataManger implements Serviceable {
    DataSource dataSource;
    public void service (ServiceManager sm) 
          throws ServiceException {
      dataSource = (DataSource)sm.lookup("dataSource");
    }
    
    public void getData() {
      //use dataSource for something
    }
}

This form of IoC has been around for longer than the term IoC has been in use — many of you might have used such a form of IoC when using the EJB framework, for example. Here, your components extend and implement specified interfaces, which then get called by the framework itself.

The fact that the Avalon framework has been providing an IoC framework for several years now, without generating nearly as much interest in the idea as either Spring or PicoContainer, is probably due to the downsides of this approach. The requirement to implement specific interfaces can give code a "bloated" feel, while at the same time coupling your application code to the underlying framework. The benefits provided by the other two forms of IoC we will look at next far outweigh those provided by this form of IoC.

Setter Injection (Type 2)

With Setter Injection IoC, some external metadata is used to resolve dependencies. In Spring, this metadata takes the form of an XML configuration file. With this form of IoC, the JDBCDataManager class looks like a normal bean:

public class JDBCDataManger {
  private DataSource dataSource;
  
  public void setDataManager(DataSource dataSource {
    this.dataSource = dataSource;
  }
  
  public void getData() {
      //use dataSource for something
  }
}

Our JDBCDataManger component exposes its dataSource property to allow Spring to set it. Spring does this using its XML configuration. First we define a data source bean (which can be reused by multiple components):

<bean id="myDataSource" 
  class="org.apache.commons.dbcp.BasicDataSource" >
  <property name="driverClassName">
    <value>com.mydb.jdbc.Driver</value>
  </property>
  <property name="url">
    <value>jdbc:mydb://server:port/mydb</value>
  </property>
  <property name="username">
    <value>root</value>
  </property>
</bean>

Next, we define an instance of our manager and pass in a reference to the data source:

<bean id="dataManager" 
  class="example.JDBCDataManger">
  <property name="dataSource">
    <ref bean="myDataSource"/>
  </property>
</bean>

At runtime, a JDBCDataManger class will be instantiated with the correct DataSource dependency resolved, and we will be able to access the bean via the Spring framework itself.

The definition of dependencies in this way makes unit testing a breeze: simply define an XML file for your mock objects, replacing your normal XML file, and away you go.

Perhaps the main advantage of Setter Injection is that application code is not tied to the container in any way, but this is also a downside — it's not immediately clear how this JDBCDataManger component relates to everything else. It almost seems as though the DataSource is being magically passed to the JDBCDataManger, as the dependency management is being done outside of the Java code. Another disadvantage is that Spring requires getters and setters for its dependency resolution. You have to expose properties that you might perhaps not otherwise expose, potentially breaking data encapsulation rules and, at best, making a class' interface more complex than is needed. With Spring's metadata being described in XML, it cannot be validated at compile time during normal Java compilation, meaning issues with broken dependencies can only be spotted at runtime.

Constructor Injection (Type 3)

Constructor Injection is based around this principle of the "Good Citizen." The Good Citizen pattern was introduced by Joshua Bloch, to describe objects that, upon creation, are fully set up and valid to use. In practice, this means that objects should not need additional methods to be called on them after instantiation in order to make them useable. The result is that you can sure that once you've created such an object, it's fit to use. This radically simplifies your code and reduces the need for defensive coding checks, while at the same time making your code more defensive as a whole. Such code is also very easy to test.

With Constructor Injection, you register an object with the framework, specify the parameters to use (which can in turn be created by the framework itself) and then just request an instance. The components being registered just have to implement a constructor, which can be used to inject the dependencies. Recently, Spring has introduced support for this form of IoC, but we'll look instead at PicoContainer, which has been built around this principle. Let's look at our JDBCDataManger, now recoded for use with a Constructor Injection framework:

public class JDBCDataManger {
  private DataSource dataSource;
  
  public JDBCDataManger(DataSource dataSource) {
    this.dataSource = dataSource;
  }
  
  public void getData() {
      //use dataSource for something
  }
}

Rather than using a configuration file, PicoContainer uses some good old-fashioned Java to glue everything together:

//create a datasource bean
BasicDataSource dataSource = new BasicDataSource();
dataSource.setDriverClassName("com.mydb.jdbc.Driver");
dataSource.setUrl("jdbc:mysql://localhost:3306/mydb");
dataSource.setUsername("Bob");

//create the container
MutablePicoContainer pico = new DefaultPicoContainer();

//register components with container
ConstantParameter dataSourceParam =
    new ConstantParameter(dataSource);
String key = "DataManager";
Parameter[] params = {dataSourceParam};

/*
 * Now each request for a DataManager will instantiate
 * a JDBCDataManager object with our defined
 * dataSource object
 */
pico.registerComponentImplementation (key,
    JDBCDataManger.class,params);

To get instances of the JDBCDataManager object, we just have to reference the class by its key:

JDBCDataManger dm =
    (JDBCDataManger)pico.getComponentInstance(key);

Like Setter Injection IoC, our application code (apart from the Pico-specific configuration) is independent of the framework itself, and also gives you the advantages inherited from the use of the Good Citizen pattern. In addition, given that PicoContainer only requires a constructor, we have to make much less provisioning for the use of an IoC framework than with Setter Injection IoC.

Potential downsides with this approach are that using constructors to maintain the dependencies can become more complex when using inheritance, and it can cause issues if you use your constructors for purposes other than simply initializing the object. (Which some do!)

IoC in Action: The Data Access Object Pattern

Currently, our JDBCDataManger class is using SQL to access our data. What if we wanted to access data via Hibernate, or JDO? We could replace the uses of JDBCDataManger with a new class, but a more elegant solution would be to use the Data Access Object (DAO) pattern. In brief, the DAO pattern defines a method by which normal value objects are used to set and retrieve data (think normal JavaBeans), and this access is done via an abstract Data Access Object. (For those of you wishing to learn more on the DAO pattern, Sun's Pattern Catalog is a good place to start.)

Our existing JDBCDataManger will remain unchanged. We will add an Interface called DataManager, which will implement our data access methods. For the sake of argument, we'll also add a Hibernate implementation, HibernateDataManager. Both JDBCDataManger and HibernateDataManager become Data Access Objects.

Assuming we were already using IoC, changing which DAO to use is a breeze. Assuming we use Spring with the code above, we can use Hibernate instead of JDBC by simply changing the XML config to resolve to the HibernateDataManager rather than the JDBCDataManger class. Likewise for PicoContainer: we just register the HibernateDataManager class instead of the JDBCDataManger. When switching between DAO implementations, our application code will remain unchanged, assuming they are just expecting the DataManager interface rather than the JDBCDataManger implementation.

By using a DAO interface with two implementations, we are combining the DAO pattern with the Abstract Factory pattern. In effect, the IoC frameworks are undertaking the role of the factory itself. Using such a pattern during development makes moving to another persistence mechanism very easy indeed, and can be of great use if your development environment uses a slightly different setup than your release environment. Both implementations of the DataManager can be in the same codebase, and switching between them is trivial.

Spring Vs. PicoContainer

PicoContainer and Spring differ little in the amount of work required to set up your IoC bindings. Spring can be configured either by an XML configuration file or directly in Java, whereas PicoContainer requires a Java binding (although the PicoExtras project does provide XML configuration support). I am rapidly coming to the conclusion that XML configuration files are becoming overused (and as someone has recently noted, all of these different configuration files are almost becoming new languages in their own right), although which approach is better is very much a matter of personal taste. Given that you may require multiple configurations (say, one for development, another for release), an XML-based system may be preferable, if only for configuration management issues.

Both are fairly "light" frameworks — they work well with other frameworks and have the added advantage of not tying you to them. PicoContainer is by far the smaller of the two; it sticks to the job of being an IoC framework and doesn't provide many supporting classes for working with external products like Hibernate. It is also worth noting that Spring is not just an IoC framework: it also provides web application and AOP frameworks, as well as some general support classes, which adds significantly to the size of the library. Personally, I found Spring's web application framework very flexible. However, it does seem to require more in the way of configuration than a framework such as Struts, and yet doesn't have as rich a set of supporting classes. In addition, the AOP features are still being developed, and you may not find it as fully featured as "pure" AOP frameworks such as AspectWerkz or AspectJ.

If you are going to use the additional supporting classes provided by Spring, then you'll find it a good choice. If, however, you are happy to implement these yourself (or rely on external projects to provide them) then Pico's small footprint might be a deciding factor. Both support Constructor Injection IoC, but only Spring supports Setter Injection -- if you prefer setter injection to constructor injection, then Spring is the obvious choice.

Conclusion

Hopefully, I have shown that by using IoC in your application that you can end up with neater, more flexible code. Both Spring and PicoContainer can be easily introduced into existing projects as part of ongoing refactoring work, and their introduction can further aid future refactoring work. Those adopting IoC from project inception will find their application code has better defined inter-component relationships, and will be more flexible and easier to test.

Sam Newman is a Java programmer. Check out his blog at magpiebrain.com.

原文作者：UbuntuWiki

授权许可：GNU General Public License

翻译／修改人员：MillenniumDark

校对人员：

适用版本：Ubuntu 5.10

文章状态：完成。

原文

注意： 以下内容可能已经过时，并经过修改，请访问UbuntuWiki获取最新的原文。

This document describes how to install Ubuntu 5.10 "Breezy Badger" for the IBM/Motorola PowerPC and Apple Power Mac ("powerpc").

本文档描述了如何在IBM/Motorola PowerPC和Apple Power Mac ("powerpc")上安装Ubuntu 5.10 "Breezy Badger"。

This How To is free; you may redistribute it and/or modify it under the terms of the GNU General Public License.

本指南是自由的；你可以再分发或修改它，但要遵循GNU公共许可证（GNU General Public License）。

1. Booting the installer

2. 引导安装程序

• Download the CD image from http://www.ubuntulinux.org/download/ and burn it to a CD. Use the Disk Utility (or similar CD burner) to burn the CD - don't just open up the .iso file into the Finder and burn from there as this won't work!

• 从http://www.ubuntulinux.org/download/下载CD镜像并烧录CD。 使用Disk Utility（或类似的CD烧录程序）烧录CD －－不要仅仅在Finder打开.iso文件并在里面烧录，这样不管用！

PowerPC

• To boot the CD on "NewWorld" Power Macs (from the blue-and-white G3 onwards), hold down the c key when booting your computer, or else Command-Option-Shift-Delete. "OldWorld" Power Macs (beige G3 and older) will not boot from CD and are not currently supported by Ubuntu.

PowerPC

• 当启动你的电脑时，按住c键，或者Command-Option-Shift-Delete，以便在"NewWorld" Power Mac（从蓝白色的G3机往后的机子）引导CD，"OldWorld" Power Mac（beige G3及更早的机子）无法从CD引导，目前不被Ubuntu支持。

A netboot install is also available, but for now it is outside the scope of this document.

网络引导安装是可用的，但是，就目前而言，这在本文档的范围之外。

• Once the installer starts, you will be greeted with a simple boot menu.

• 一旦安装程序启动，你将见到一个简单的引导菜单。

• Press Enter to boot, or use one of the other boot methods described on this screen.

• 按下Enter来进行引导，或者使用屏幕上描述的其他引导方法。

3. First stage of installation

4. 安装的第一阶段

After a few moments, you will be asked to select your language.

过了一段时间，会让你选择语言。

• Use the arrow keys to pick a language and press Enter to continue.

• 使用箭头箭选择一种语言，按Enter继续。

• Next you'll be asked to select a country, with the choices including countries where your language is spoken. If it's not on the short list, choose "other" to see a list of all the countries in the world.

• 接着会让你选择国家，提供的选项是使用你的语言的国家。如果其中没有你的国家，选择other（其他），你将会看到包含世界上所有国家的列表。

• You will be asked to choose your keyboard layout.

• 将让你选择键盘布局。

• Now sit back while the installer detects some of your hardware, and loads the rest of itself from the CD.

• 现在你可以休息一下，安装程序将探测你的一些硬件，并从CD装载它的剩余部分。

• Next the installer will try to detect your network hardware and set up networking by DHCP. If you are not on a network or do not have DHCP, you will be given the opportunity to configure the network manually.

• 接着安装程序将尝试探测你的网络硬件并通过DHCP设置网络。如果你未联网或没有DHCP，你需要手动配置网络。

4.1. Partition your disk

4.2. 分区

• First you will be given the opportunity to erase and automatically partition an entire disk. This is recommended for new users, but if you have any valuable data on the disk, be sure to back it up first, as it will be erased!

• 第一个选项是擦除整个硬盘，然后自动分区。建议新手选这一项。不过，如果你的硬盘上有有价值的数据，一定要先备份，因为它们会被擦去。

• If you are dual booting with Mac OSX and Ubuntu, you should already have Mac OSX installed. This way the yaboot configuration will see the OSX install and automatically add it to the boot map options when you startup. To change the default OS see /etc/yaboot.conf.

• 如果你打算Mac OSX和Ubuntu双启动，你应该已经安装了Mac OSX。这样的话，yaboot配置程序会检测到OSX安装，并自动将其加入boot map的选项里。要改变默认的操作，看看/etc/yaboot.conf。

• If you do not want to edit the partition table manually, and you are dual booting, select "use the largest continous free space."(Given that this is where you want ubuntu to be installed.) This will automatically partition the drive for you leaving your other OS untouched. (This also assumes you have your alternate OS already installed, and a large area of free space in which to install Ubuntu.

• 若 不想手工修改分区表，同时希望双启动，选择use the largest continous free space（使用最大的连续空闲空间），（前提是你想把Ubuntu装在这儿。）这将自动分区，不会影响其他操作系统。（这里同样假设你调整了已经安装的 操作系统，空出一大块空闲空间安装Ubuntu。）

• If you do not want to erase an entire disk, or if you want to customize the partition layout, choose "Manually edit partition table" from the menu, and the next screen will show you your partition table, how the partitions will be formatted, and where they will be mounted.

• 如不想擦除整块硬盘，或打算定制分区布局，在菜单中选择Manually edit partition table（手工编辑分区表）。

接下的安装过程和在x86系统上的安装基本相同，请参考在x86系统上安装Ubuntu的文档。

UbuntuChina Wiki: UbuntuOnPPC (last edited 2006-05-03 16:47:13 by MillenniumDark)

sudo gedit /usr/sbin/autowinfs

#!/bin/sh
#
#autowinfs    auto mount windows disks
#
# Copyright (c) 2005   Jiahua Huang <jhuangjiahua@gmail.com>
#License: GPLv2

#
#  /usr/bin/sutowinfs
#  用来自动挂载机器上的 Windows 分区 ， 并写入 /etc/fstab
#   五  2月 18 14:06:12 CST 2005

mkdir  -p  /windows/
rmdir   /windows/*   1> /dev/null
grep  -v  '/windows/'  /etc/fstab  >  /etc/fstab.swp


#  本脚本用于 UTF-8 的 Locale 下 
#  单独的 fdisk  -l  不能列出分区的情况很少了 ， 所以把  /dev/[hs]d[a-z]  去掉
## fdisk  -l  /dev/[hs]d[a-z]  |  grep   -E  'FAT|NTFS'  | cut -d' ' -f1    |   cut -d/ -f3  |   while read WDISKS
# 查找 NTFS 分区  ， 新内核的 auto 好像有点问题 ， 所以现在把  NTFS 和 VFST 分开来

fdisk  -l /dev/[hs]d[a-z]  |  grep     'NTFS'  | cut -d' ' -f1    |   cut -d/ -f3  |   while read WDISKS
     do echo  "/dev/$WDISKS  /windows/$WDISKS  ntfs  auto,user,nls=utf8,umask=0   0 0"    >>  /etc/fstab.swp
     mkdir  "/windows/$WDISKS"
done

fdisk  -l /dev/[hs]d[a-z]  |  grep     'FAT'  | cut -d' ' -f1    |   cut -d/ -f3  |   while read WDISKS
     do echo  "/dev/$WDISKS  /windows/$WDISKS  vfat  auto,user,utf8,umask=0   0 0"    >>  /etc/fstab.swp
     mkdir  "/windows/$WDISKS"
done

mv   /etc/fstab.swp    /etc/fstab
mount   -a
exit  0

sudo chmod +x /usr/sbin/autowinfs
sudo /usr/sbin/autowinfs