李 越 wrote:
> Thank you , by the way, I m a Chinese, yet you can call me Mike,it is
> easy for a none-Chinese to pronounce.
My appologies. Kanji is derived from the Chinese writing system, so they
do look alot alike.
>
> When I use ECM, I have my class a pirvate member of
> ExcaliburComponentManager type, and I initialized it this way:
> myManager= new
> ExcaliburComponentManager(this.getClass().getClassLoader()); thus all
> components used by this class or the children class of this class can be
> looked up by this manager, my class is therefore a container, is this
> right?
Essentially--but it is the marriage of the lookup and containment concerns
in the ECM that give way to many hacks.
> Now come back to fortress, FortressConfig has a method
> setContainerClass(String myclass), I guess by using this method, I can
> turn myclass into a Container which is rightly an
> org.apache.avalon.fortress.Container, is this right?
Yes. However that method is used only to *override* the DefaultContainer that
Fortress initializes with. All you would have to do to use the default
container is get the config files right.
> And,by setContainerConfiguration(),I can set to this Container a
> Configuration which has the same content as in the .xconf file I used
> for ECM--which is a list of configuration for all components using
> shorthand names, and, by using setRoleManager() method, I can tell the
> container the roles related to those shorthandnames.Or, if I decide to
> use MetaInfo instead of roles files, I can use setMetaInfoMananer()
> method( although I do not know how to construct a MetaInfoManager now)is
> this right?
Essentially yes, but the default container does have two key differences
from the ECM.
1) All components must have the attribute id="unique.name" which is used if
the component is looked up via a Selector (in Fortress you can use a selector
or the more direct "ROLE/hint" idiom). If the configuration element does not
have the "id" attribute, then the container assumes that information is not
for any components.
2) All components have to be listed in the .xconf file, even if they are not
configurable.
> Ok, now I have a Container for myclass (which maybe a bootstrap class),
> should I use Container.getServiceManager() method to get a
> ServiceManager and then use the lookup method of it to lookup a service?
> but how this ServiceManager get all the information--mainly information
> in my .xconf and .roles files I passed to Container? and is this
> ServiceManager I got is a FortressServiceManager? why not construct a
> FortressManager without caring about a Container? I mean, for example,
> let this FortressServiceManager have a RoleManager and a configure()
> method to read in the content in a .xconf file so that it can understand
> the shorthand names of roles?
Before experimenting with your own flavors of containers, use what is provided
by default. But to answer your question: yes, always look up the components
through the supplied ServiceManager.
> And, why there must be a FortressConfig and also a CotainerManager? why
> not just let the Container itself have methods such as, for example,
> setRoleManager() instead of having those methods defined in
> FortressConfig and then use the context of that FortressConfig to
> construct a ContainerManager?
For two reasons:
1) Fortress was designed to be extensible so that you can override the default
container if need be. You cannot make assumptions about all those methods
when you can have any class potentially be a component, nor would you want
to force every container to implement all those methods. The FortressConfig
provides a standard interface to set up the environment to begin with no
matter what.
2) The ContainerManager is a special purpose Container that holds only one
component: your container. It uses all the information passed in by the
FortressConfig to actually set up your environment, and starts it up.
> By the way, what are these two statemetns for?
> config.setContextDirectory( "./" );
> config.setWorkDirectory( "./" );
They are used to tell the Container where to resolve relative files, and where
it is safe to save temporary work information. They default to the value
returned by System.getProperty("user.dir") which is typically the directory
you started executing the system from.
They are convenient when you are integrating with a web environment, and you
want to set the context directory (the relative URL location) to the same for
your servlet, as well as set the work directory to the servlet's work directory.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
