well,I saw the below blcok in the API doc of interface ContainerManager
FortressConfig config = new FortressConfig();
config.setContainerClass( Thread.currentThread().getContextClassLoader().loadClass( "org.apache.avalon.fortress.test.TestContainer" ) );
config.setContextDirectory( "./" );
config.setWorkDirectory( "./" );
config.setContainerConfiguration( "resource://org.apache.avalon.fortress/test/ContainerProfile.xconf" );
config.setLoggerManagerConfiguration( "resource://org.apache.avalon.fortress/test/ContainerProfile.xlog" );
ContainerManager cm = new DefaultContainerManager( config.getContext() );
ContainerUtil.initialize( cm );
Container myContainer=cm.getContainer();
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?
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?
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?
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?
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?
By the way, what are these two statemetns for? config.setContextDirectory( "./" ); config.setWorkDirectory( "./" );
Regards. Mike.
From: Berin Loritsch <[EMAIL PROTECTED]>service in fortress
Reply-To: "Avalon framework users" <[EMAIL PROTECTED]>
To: Avalon framework users <[EMAIL PROTECTED]>
Subject: Re: where can I find a sample code demonstrating how to lookup a
Date: Thu, 08 Jan 2004 08:56:58 -0500what
李 越 wrote:
> in ECM, I use only ComponentManager and ComponentSelector and roles > files to do this, yet in fortress, I have the following questions
I will do my best to answer them. BTW, I have not learned Kanji yet, how would you spell your name in say Romanji? (I barely begain taking some online Japanese lessons).
>
> 1>why there is an org.apache.avalon.fortress.Container in fortress?
ComponentManager> is this Container for? because I think what ComponentManager and > ComponentSelector do in ECM can be totally done by SericeManager and > ServiceSelector that are encouraged to use in fortress, and, besides, > what is ComponentHandler for in fortress, how to use it
This interface is used to work with the FortressServiceManager and
FortressServiceSelector classes. It is not necessarily something you
have to worry about in your projects. While Fortress does encourage you
to move on to using the preferred ServiceManager and ServiceSelector
interfaces, you can still use your old components that use the
and ComponentSelectors. It will work seemlessly with both.over
> 2> It mentions in 'Use meta info' on fortress page on avalon site that > the 'roles' files are not encouraged to use in fortress, instead, > fortress use javadoc meta information to get meta information for a > Service,I did the following:
You are correct. There are a number of advantages of generated meta info
a roles file. The meta info is kept with the class so that you only haveto
maintain your source code. It works beautifully. Not to mention with themeta
info you can have one component implement more than one role. While thenecessary--especially
practice is not necessarily encouraged, sometimes it is
while refactoring your component interfaces.was
> this is my build.xml file
Reformatted below:
<?xml version="1.0" encoding="GB2312" ?> <project default="dist" basedir="."> <property environment="env"/> <property name="java.home" value="${env.JAVA_HOME}"/> <property name="ant.home" value="${env.ANT_HOME}"/> <property name="src.dir" value="src"/> <property name="build.dir" value="build" /> <property name="build.classes" value="${build.dir}/classes"/> <taskdef name="collect-metainfo" classname="org.apache.avalon.fortress.tools.ComponentMetaInfoCollector"> <classpath> <pathelement location="fortress-tools.jar"/> <pathelement location="qdox-1.3.jar"/> </classpath> </taskdef> <target name="compile" description="Compiles the source code"> <mkdir dir="${build.classes}"/> <javac srcdir="${src.dir}" destdir="${build.classes}"> <classpath> <fileset dir="." includes="*.jar"/> <pathelement location="${java.home}"/> <pathelement location="${ant.home}"/> </classpath> </javac> <collect-metainfo destdir="${build.classes}"> <fileset dir="${src.dir}"/> </collect-metainfo> </target> </project>
The only thing that looks like it might break is the qdox JAR. The tool
developed to work against QDox 1.2--and if they changed the API in any wayfor
the newer version you are using, then it will break the tool.excalibur-fortress-1.0\examples\src\java\org\apache\avalon\fortress\examples\components
> and I put these jar files in the "." (current dir) directory
> in the /src dir , I have two files got from
>
safe> > they are Translator.java and TranslatorImpl.java > > avalon-framework-4.1.4.jar excalibur-fortress-complete-1.0.jar > fortress-tools.jar qdox-1.3.jar > I ran the build file and got the exception: > > java.lang.IncompatibleClassChangeError at
<snip type="stacktrace"/>
I have to ask, what JVM are you using? The Fortress stuff has been compiled to be compatible with Java 1.2 and up, but since QDox is out of our control it may have been compiled against Java 1.4.
> When I did this , I just tried to see what files the > ComponentMetaInfoCollector can generate and how they differ from the > orginal roles files of ECM. > > So anyone can be so nice to tell me why the exceptions occured?
I suspect that the QDox 1.3 JAR was compiled against a later JVM than you are using. Information on the JVM and OS of the machine you are running may help me understand if anything else is going on.
> 3> what is the MetaInfoManager for in fortress? how to use it? and why > there is still a RoleManage in fortress? is it still of use?
The MetaInfoManager is used internally with the container (as is the RoleManager). The MetaInfoManager reads the meta info fromt the JAR files so that the container knows how to interpret the configuration file and locate all the services/components at the container's disposal.
The AbstractMetaInfoManager has constructors to allow it to wrap the older
RoleManager so that it can still be used. It probably would have been
to remove the RoleManager, but I left it in just in case someoneimplemented
their own.to
> I m sorry to ask so many 'simple' questions, yet I m really at a loss
> know how to transfer my code that exploits ECM to code using fortressidea.
It's ok. How else will you learn?
--
"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]
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
