李 越 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? what
> 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 ComponentManager
and ComponentSelectors. It will work seemlessly with both.
> 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 over
a roles file. The meta info is kept with the class so that you only have to
maintain your source code. It works beautifully. Not to mention with the meta
info you can have one component implement more than one role. While the
practice is not necessarily encouraged, sometimes it is necessary--especially
while refactoring your component interfaces.
> 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 was
developed to work against QDox 1.2--and if they changed the API in any way for
the newer version you are using, then it will break the tool.
> and I put these jar files in the "." (current dir) directory
> in the /src dir , I have two files got from
> excalibur-fortress-1.0\examples\src\java\org\apache\avalon\fortress\examples\components
>
>
> 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 safe
to remove the RoleManager, but I left it in just in case someone implemented
their own.
> I m sorry to ask so many 'simple' questions, yet I m really at a loss to
> know how to transfer my code that exploits ECM to code using fortress idea.
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]
