You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/05/21 21:45:33 UTC
[Announce] Excalibur Phase III Release Candidate 3 available
I believe we are at the final iteration of the release candidates
for Phase III Excalibur projects. Please note that there are two
fewer offerings for the time being. Both XMLUtil and Excalibur Store
have been postponed to be released at a later time.
You may examine the release candidates here:
http://avalon.apache.org/~bloritsch/excalibur-dist/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Release the Excalibur Phase III components
Posted by Leo Simons <le...@apache.org>.
+1
- Leo Simons
Berin Loritsch wrote:
> releasing the set of components at this URL
>
> http://avalon.apache.org/~bloritsch/excalibur-dist/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[VOTE] Release the Excalibur Phase III components
Posted by Berin Loritsch <bl...@apache.org>.
So that we can get Fortress out there, how about releasing
the set of components at this URL
http://avalon.apache.org/~bloritsch/excalibur-dist/
+1 from me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress.tools] [PATCH] fix shared repository not cleared bug
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
>
> Have just found a bug in Fortress ComponentMetaInfoCollector.
Thank you very much for all your help. Let me update the release
candidate and see if we can get a no errors report!
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Fortress.tools] [PATCH] fix shared repository not cleared bug
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
Have just found a bug in Fortress ComponentMetaInfoCollector.
1. Testcase
I propose a test case for this bug. The test case is not a usual
one, it is an additional build.xml file called from
<target name="test"> in the main fortress build.xml:
--- build.orig 2003-05-20 09:33:52.000000000 +0400
+++ build.xml 2003-05-22 13:37:27.000000000 +0400
@@ -336,6 +336,8 @@
</batchtest>
</junit>
+ <ant antfile="${build.testsrc}/org/apache/avalon/fortress/tools/test/build.xml"/>
+
</target>
<target name="test-reports" depends="test" description="Generate Reports for the unit tests">
=====
and here's the file that I propose to put to
src/test/org/apache/avalon/fortress/tools/test/build.xml
=====
<?xml version="1.0"?>
<project name="Test Excalibur Fortress collect-meta double invocation" default="main">
<taskdef name="collect-meta"
classname="org.apache.avalon.fortress.tools.ComponentMetaInfoCollector"
classpath="${cp}"/>
<target name="main">
<property name="destination"
value="${build.testclasses}/org/apache/avalon/fortress/tools/test"/>
<property name="meta-dir-1"
value="${destination}/meta1"/>
<property name="meta-dir-2"
value="${destination}/meta2"/>
<mkdir dir="${meta-dir-1}"/>
<mkdir dir="${meta-dir-2}"/>
<copy todir="${meta-dir-1}">
<fileset dir="${build.testsrc}">
<include name="**/data"/>
</fileset>
</copy>
<copy todir="${meta-dir-2}">
<fileset dir="${build.testsrc}">
<include name="**/data"/>
</fileset>
</copy>
<collect-meta destdir="${meta-dir-1}">
<fileset dir="${build.testsrc}">
<include name="**/Component1.java"/>
</fileset>
</collect-meta>
<collect-meta destdir="${meta-dir-2}">
<fileset dir="${build.testsrc}">
<include name="**/Component2.java"/>
</fileset>
</collect-meta>
</target>
</project>
You see that I just invoke collect-meta twice
with different output directories (and different input
filesets).
The error that you will see with this test case is
a CyclicDependecyException, but I also have seen a
FileNotFoundException in my own project.
The reason is that Component.m_repository is shared
between invocations and not cleared from one invocation
to another. I suspect that it is not much use to try
to find out why excactly a CyclicDependency or FileNotFound,
but just to clear it, so
2. Fix.
Quite simple :-)
--- ComponentMetaInfoCollector.orig 2003-05-16 09:49:10.000000000 +0400
+++ ComponentMetaInfoCollector.java 2003-05-22 13:34:00.000000000 +0400
@@ -137,6 +137,10 @@
{
throw new BuildException( e.toString(), e );
}
+ finally
+ {
+ Component.m_repository.clear();
+ }
}
/**
- WBR, Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] MetaInfoManager/RoleManager relationship
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Anton Tagunov wrote:
>>
>> AT> 3. Berin, please also note that those and the same patch
>> AT> to SourceResolve also adds @avalon.dependency on
>> AT> SourceFactory to SourceResolverImpl.java
>> AT> I beleive you will want this change too.
>>
>> BL> The attributes are on the implementations--I could have swarn
>> BL> I already did that (or somebody did).
>>
>> Yes, they are there, but this one, @avalon.dependency was missing!
>> SourceResolverImpl does depend on ResourceFactory, doesn't it? ;-)
You were looking in the wrong place. It should be in the JavaDoc
for the service() method.
BTW, the Deps generation info is fixed as well as a bug in the DAG
verification code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Fortress] MetaInfoManager/RoleManager relationship (was Re: [Announce]
Excalibur Phase III Release Candidate 3 available)
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
>
> AT> user may rely on the fact that
> AT> lookup( MetaInfoManager.ROLE ) will return something.
>
> BL> Actually any more this is not guaranteed. The changes you made
> BL> to the ContextManager made the initializeMetaManager do nothing,
> BL> so I removed the method. Unless the user explicitly supplies the
> BL> MetaManager, it will not be set.
>
> Hmm.. It is the AbstractContainer now that creates a
> ServiceMetaManager, maybe we could do something like this?
>
> - m_serviceManager = new FortressServiceManager( this, serviceManager );
> + localSM = new DefaultServiceManager( serviceManager );
> + localSM.put( MetaInfoManager.ROLE, m_metaManager );
> + m_serviceManager = new FortressServiceManager( this, serviceManager );
Yep.
> BL> Or at least the RoleManager. That
> BL> way the contract is that the MetaInfoManager.ROLE is always
> BL> available, but the RoleManager is only available to the
> BL> direct child container.
>
> Berin, I feel that may be a good idea but I'm afraid I've lost my way
> a bit: what does "child container" here stand for? Does it stand for
> "a" or for "b" in the following schema:
>
> DefaultContainerManager
> DefaultContainer <--- a
> CustomContainerA <--- b
b is what I am talking about.
>
> (this has pushed me to create Patch #5,
> I'm sorry about so much patches in one day :-)
:) Its ok. I want to get this done, but of course it is better
to have a good release.
>
> AT> I have made the changes to SourceResolve
> AT> ...
> AT> * excalibur-fortress-tools.jar
> AT> * qdox.jar
>
> BL> The big thing is the whole GUMP build. This introduces a circular
> BL> dependency on Fortress and SourceResolve.
>
> Please give Patch #4 a second look!
>
> I beleive that it solves the chicken-and-egg problem!
>
> I put the statically generated .meta and .deps under ./src
> and if fortress-tools is not found the static ones are used.
>
> So we have Fortress depending on SourceResolve,
> and not vice-versa!! :-)))
>
> Does not this really chop a knot we could not untie?
> What do you think of it?
It's somewhat of a hack--but it is something we need to look at.
I still think a Tools mini-project would be good, which would
incorporate XFC, Fortress tools, etc.
Let's take this one step at a time. After the Fortress 1.0
release, I want to look at standardizing the way we store
the meta-information.
>
> AT> 3. Berin, please also note that those and the same patch
> AT> to SourceResolve also adds @avalon.dependency on
> AT> SourceFactory to SourceResolverImpl.java
> AT> I beleive you will want this change too.
>
> BL> The attributes are on the implementations--I could have swarn
> BL> I already did that (or somebody did).
>
> Yes, they are there, but this one, @avalon.dependency was missing!
> SourceResolverImpl does depend on ResourceFactory, doesn't it? ;-)
Ok.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [Announce] Excalibur Phase III Release Candidate 3 available
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
AT> user may rely on the fact that
AT> lookup( MetaInfoManager.ROLE ) will return something.
BL> Actually any more this is not guaranteed. The changes you made
BL> to the ContextManager made the initializeMetaManager do nothing,
BL> so I removed the method. Unless the user explicitly supplies the
BL> MetaManager, it will not be set.
Hmm.. It is the AbstractContainer now that creates a
ServiceMetaManager, maybe we could do something like this?
- m_serviceManager = new FortressServiceManager( this, serviceManager );
+ localSM = new DefaultServiceManager( serviceManager );
+ localSM.put( MetaInfoManager.ROLE, m_metaManager );
+ m_serviceManager = new FortressServiceManager( this, serviceManager );
AT> However, currenlty lookup( RoleManager.ROLE ) also ALWAYS
AT> returns something. If users start writing applications
AT> relying on that and if we take RoleManager away later
AT> we may sort of brake backwards compatibility..
BL> This is a problem, but we also have a chicken and the egg problem.
BL> We can't remove the RoleManager concept unless we outfit all our
BL> released components with the Meta Information that is necessary.
BL> The FortressRoleManager was written when Fortress was new so that
BL> the user didn't have to write a roles file for excalibur components.
We can do this -- see bellow! :-))
BL> We would have to make it explicitly known to our users that the
BL> FortressRoleManager concept would be going away, and that they
BL> would have to hand-write the Roles file for those components,
BL> unless we provide a .roles file for them.
It would also be viable desision.
AT>
AT> Oh, am I talking crap? Most likely users will never do
AT> lookup( RoleManager.ROLE )... only maybe for writing
AT> nested containers...
AT>
BL> No, you have a good point. The only entities that would look
BL> up RoleManagers or MetaManagers are containers. We can
BL> manage some of those entries so that the container hides them
BL> from regular components.
BL> Or at least the RoleManager. That
BL> way the contract is that the MetaInfoManager.ROLE is always
BL> available, but the RoleManager is only available to the
BL> direct child container.
Berin, I feel that may be a good idea but I'm afraid I've lost my way
a bit: what does "child container" here stand for? Does it stand for
"a" or for "b" in the following schema:
DefaultContainerManager
DefaultContainer <--- a
CustomContainerA <--- b
(this has pushed me to create Patch #5,
I'm sorry about so much patches in one day :-)
AT> I have made the changes to SourceResolve
AT> ...
AT> * excalibur-fortress-tools.jar
AT> * qdox.jar
BL> The big thing is the whole GUMP build. This introduces a circular
BL> dependency on Fortress and SourceResolve.
Please give Patch #4 a second look!
I beleive that it solves the chicken-and-egg problem!
I put the statically generated .meta and .deps under ./src
and if fortress-tools is not found the static ones are used.
So we have Fortress depending on SourceResolve,
and not vice-versa!! :-)))
Does not this really chop a knot we could not untie?
What do you think of it?
AT> 3. Berin, please also note that those and the same patch
AT> to SourceResolve also adds @avalon.dependency on
AT> SourceFactory to SourceResolverImpl.java
AT> I beleive you will want this change too.
BL> The attributes are on the implementations--I could have swarn
BL> I already did that (or somebody did).
Yes, they are there, but this one, @avalon.dependency was missing!
SourceResolverImpl does depend on ResourceFactory, doesn't it? ;-)
AT> excalibur-fortress-tools.jar/<collect-meta>
AT> does not generate .deps for me.
BL> Ok. I will look into that. It is rather important.
Good luck! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Announce] Excalibur Phase III Release Candidate 3 available
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
>
> I'm sorry, Berin, you have to re-present the release candidates
> over and over again, but there still seems to be material for
> one or two more :-)
>
> This being said I do beleive we can make it a week-to-two-weeks
> time frame!
>
>
> 1. Accidentially a part of my patch to Role2InfoManager has
> been left out of the last update. Using this opportunity
> I also propose to beautify my build.xml testcase for
> collect-meta. A patch doing both of these will follow
> in an "answer" ot this mail.
I got your patch. Thanks. I will start incorporating it RSN.
Is there a hidden bug this fixes?
>
> 2. Berin, here's my reasoning what more may be done
> (and why I want it prior to the release)
>
> I beleive FortressRoleManager pollutes user contract of
> Fortress: the reality is the user may rely on the fact
> that lookup( MetaInfoManager.ROLE ) will return something.
> This is guaranteed.
Actually any more this is not guaranteed. The changes you made
to the ContextManager made the initializeMetaManager do nothing,
so I removed the method. Unless the user explicitly supplies the
MetaManager, it will not be set.
> However, currenlty lookup( RoleManager.ROLE ) also ALWAYS
> returns something. If users start writing applications
> relying on that and if we take RoleManager away later
> we may sort of brake backwards compatibility..
This is a problem, but we also have a chicken and the egg problem.
We can't remove the RoleManager concept unless we outfit all our
released components with the Meta Information that is necessary.
The FortressRoleManager was written when Fortress was new so that
the user didn't have to write a roles file for excalibur components.
We would have to make it explicitly known to our users that the
FortressRoleManager concept would be going away, and that they
would have to hand-write the Roles file for those components,
unless we provide a .roles file for them.
>
> Oh, am I talking crap? Most likely users will never do
> lookup( RoleManager.ROLE )... only maybe for writing
> nested containers...
>
No, you have a good point. The only entities that would look
up RoleManagers or MetaManagers are containers. We can
manage some of those entries so that the container hides them
from regular components. Or at least the RoleManager. That
way the contract is that the MetaInfoManager.ROLE is always
available, but the RoleManager is only available to the
direct child container.
> Anyway this class sort of messes the design.
> I have already written that we shall have to add
> the Source factories there as well if we want to make
> it really usable. And that we may take away everything
> except SourceResolve from it (to eliminate runtime-warings
> about classes not found)...
:)
>
> So, to be short -- I have made the changes to SourceResolve
> project. With my changes
> if
> * excalibur-fortress-tools.jar
> * qdox.jar
> are found then the meta info is autogenerated
>
> otherwise
> as a workaround statically present in ./src fortress meta
> info is present.
>
> But code speaks better then words -- the changes will follow
> in another letter.
The big thing is the whole GUMP build. This introduces a circular
dependency on Fortress and SourceResolve.
>
> 3. Berin, please also note that those and the same patch
> to SourceResolve also adds @avalon.dependency on
> SourceFactory to SourceResolverImpl.java
> I beleive you will want this change too.
The attributes are on the implementations--I could have swarn
I already did that (or somebody did).
>
> 4. Berin, please note that for some reason
> excalibur-fortress-tools.jar/<collect-meta>
> does not generate .deps for me.
>
> It does not generate them for my own project and
> it does not generate them in the modified sourceresolve
> project
Ok. I will look into that. It is rather important.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Patch #6
Posted by Anton Tagunov <at...@mail.cnt.ru>.
I have already sent this patch before, but to put all my patches
together I'm giving it a number and sending again.
diff -ru src.orig/java/org/apache/avalon/excalibur/monitor/ActiveMonitor.java src/java/org/apache/avalon/excalibur/monitor/ActiveMonitor.java
--- src.orig/java/org/apache/avalon/excalibur/monitor/ActiveMonitor.java 2003-03-22 15:46:50.000000000 +0300
+++ src/java/org/apache/avalon/excalibur/monitor/ActiveMonitor.java 2003-05-21 11:41:57.000000000 +0400
@@ -64,16 +64,21 @@
* looks like this:
*
* <pre>
- * <monitor>
+ * <active-monitor id="first-monitor">
* <thread priority="<i>5</i>" frequency="<i>60000</i>"/>
* <init-resources>
* <-- This entry can be repeated for every resource you want to register immediately -->
*
* <resource key="<i>file:./myfile.html</i>" class="<i>org.apache.avalon.excalibur.monitor.FileResource</i>"/>
* </init-resources>
- * </monitor>
+ * </active-monitor>
* </pre>
*
+ * @avalon.component
+ * @avalon.service type=org.apache.avalon.excalibur.monitor.Monitor
+ * @x-avalon.info name=active-monitor
+ * @x-avalon.lifestyle type=singleton
+ *
* @author <a href="mailto:bloritsch@apache.org">Berin Loritsch</a>
* @version $Id: ActiveMonitor.java,v 1.19 2003/03/22 12:46:50 leosimons Exp $
*/
diff -ru src.orig/java/org/apache/avalon/excalibur/monitor/PassiveMonitor.java src/java/org/apache/avalon/excalibur/monitor/PassiveMonitor.java
--- src.orig/java/org/apache/avalon/excalibur/monitor/PassiveMonitor.java 2003-03-22 15:46:50.000000000 +0300
+++ src/java/org/apache/avalon/excalibur/monitor/PassiveMonitor.java 2003-05-21 11:42:05.000000000 +0400
@@ -63,15 +63,20 @@
* looks like this:
*
* <pre>
- * <monitor>
+ * <passive-monitor id="second-monitor">
* <init-resources>
* <-- This entry can be repeated for every resource you want to register immediately -->
*
* <resource key="<i>file:./myfile.html</i>" class="<i>org.apache.avalon.excalibur.monitor.FileMonitor</i>"/>
* </init-resources>
- * </monitor>
+ * </passive-monitor>
* </pre>
*
+ * @avalon.component
+ * @avalon.service type=org.apache.avalon.excalibur.monitor.Monitor
+ * @x-avalon.info name=passive-monitor
+ * @x-avalon.lifestyle type=singleton
+ *
* @author <a href="mailto:bloritsch@apache.org">Berin Loritsch</a>
* @version $Id: PassiveMonitor.java,v 1.15 2003/03/22 12:46:50 leosimons Exp $
*/
diff -ru src.orig/java/org/apache/avalon/excalibur/monitor/impl/ActiveMonitor.java src/java/org/apache/avalon/excalibur/monitor/impl/ActiveMonitor.java
--- src.orig/java/org/apache/avalon/excalibur/monitor/impl/ActiveMonitor.java 2003-05-21 11:00:26.000000000 +0400
+++ src/java/org/apache/avalon/excalibur/monitor/impl/ActiveMonitor.java 2003-05-21 11:25:24.000000000 +0400
@@ -54,11 +54,6 @@
* changed. It will poll the resources with a frequency as specified or if
* unspecified with the default (60 seconds).
*
- * @avalon.component
- * @avalon.service type=org.apache.avalon.excalibur.monitor.Monitor
- * @x-avalon.info name=active-monitor
- * @x-avalon.lifestyle type=singleton
- *
* @author <a href="mailto:bloritsch@apache.org">Berin Loritsch</a>
* @author <a href="mailto:peter at apache.org">Peter Donald</a>
* @version $Id: ActiveMonitor.java,v 1.8 2003/05/20 20:49:35 bloritsch Exp $
diff -ru src.orig/java/org/apache/avalon/excalibur/monitor/impl/PassiveMonitor.java src/java/org/apache/avalon/excalibur/monitor/impl/PassiveMonitor.java
--- src.orig/java/org/apache/avalon/excalibur/monitor/impl/PassiveMonitor.java 2003-05-21 11:00:28.000000000 +0400
+++ src/java/org/apache/avalon/excalibur/monitor/impl/PassiveMonitor.java 2003-05-21 11:25:50.000000000 +0400
@@ -59,11 +59,6 @@
* A passive monitor will check the reosurce each time it
* is accessed.
*
- * @avalon.component
- * @avalon.service type=org.apache.avalon.excalibur.monitor.Monitor
- * @x-avalon.info name=passive-monitor
- * @x-avalon.lifestyle type=singleton
- *
* @author <a href="mailto:bloritsch@apache.org">Berin Loritsch</a>
* @author <a href="mailto:peter at apache.org">Peter Donald</a>
* @version $Revision: 1.7 $ $Date: 2003/05/20 20:49:35 $
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Patch] #4 Add Fortress Meta info to SourceResolve
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
>
> Uff.. At last -- I've done it :-)
> Now SourceResolve can be shipped with Fortress meta
> descriptors. I hope it's even somewhat elegant :-)
>
> Plz also note
> 1. @avalon.dependency has been added to SourceResolverImpl
> 2. SourceResolverImpl.deps file does not get generated for
> some reason I failed to debug.
The deps should be a real class name. Otherwise Fortress
won't be able to add the dependency.... Hmmm.
Some of them are listed as XXXSelector which I believe is
wrong.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Patch] #4 Add Fortress Meta info to SourceResolve
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
Uff.. At last -- I've done it :-)
Now SourceResolve can be shipped with Fortress meta
descriptors. I hope it's even somewhat elegant :-)
Plz also note
1. @avalon.dependency has been added to SourceResolverImpl
2. SourceResolverImpl.deps file does not get generated for
some reason I failed to debug.
WBR, Anton
diff -ru sourceresolve.0/build.xml sourceresolve/build.xml
--- sourceresolve.0/build.xml 2003-05-21 11:00:32.000000000 +0400
+++ sourceresolve/build.xml 2003-05-23 13:34:12.000000000 +0400
@@ -72,6 +72,7 @@
</fileset>
</copy>
+ <ant antfile="fortress-meta.xml"/>
</target>
<!-- Compiles the unit test source code -->
diff -ru sourceresolve.0/default.properties sourceresolve/default.properties
--- sourceresolve.0/default.properties 2003-02-06 16:38:34.000000000 +0300
+++ sourceresolve/default.properties 2003-05-23 13:18:37.000000000 +0400
@@ -21,6 +21,18 @@
avalon-framework.jar=${avalon-framework.lib}/avalon-framework.jar
# --------------------------------------------------
+# OPTIONAL LIBRARIES
+# --------------------------------------------------
+# ----- Avalon Fortress, version 1.0 or later -----
+avalon-fortress.home=${basedir}/../fortress
+avalon-fortress.lib=${avalon-fortress.home}/dist
+avalon-fortress-tools.jar=${avalon-fortress.lib}/excalibur-fortress-tools-1.0.jar
+# ----- QDox Jar ----
+qdox.jar=${basedir}/../lib/qdox-1.1.jar
+
+
+
+# --------------------------------------------------
# Settings used to configure compile environment
build.debug = on
@@ -44,6 +56,7 @@
java.dir = ${src.dir}/java
conf.dir = ${src.dir}/conf
test.dir = ${src.dir}/test
+fortress-static-meta.dir = ${src.dir}/fortress.meta
# needed by Cocoon
build.context = ${build.dir}/documentation
diff -ru sourceresolve.0/src/java/org/apache/excalibur/source/impl/SourceResolverImpl.java sourceresolve/src/java/org/apache/excalibur/source/impl/SourceResolverImpl.java
--- sourceresolve.0/src/java/org/apache/excalibur/source/impl/SourceResolverImpl.java 2003-05-21 11:00:40.000000000 +0400
+++ sourceresolve/src/java/org/apache/excalibur/source/impl/SourceResolverImpl.java 2003-05-23 13:22:09.000000000 +0400
@@ -92,6 +92,7 @@
*
* @avalon.component
* @avalon.service type=SourceResolver
+ * @avalon.dependency type=org.apache.excalibur.source.SourceFactory
* @x-avalon.info name=resolver
* @x-avalon.lifestyle type=singleton
*
and now fortress-meta.xml to be put to the root of the SourceResolving
project
<?xml version="1.0"?>
<project name="Excalibur SourceResolving Fortress Meta Info Management" basedir="."
default="provide-fortress-meta">
<property file="${user.home}/build.properties"/>
<property file="${basedir}/../ant.properties"/>
<property file="${basedir}/ant.properties"/>
<property file="${user.home}/.ant.properties"/>
<property file="${basedir}/../libraries.properties"/>
<property file="${basedir}/../default.properties"/>
<property file="${basedir}/default.properties"/>
<path id="fortress.tools.classpath">
<pathelement location="${avalon-fortress-tools.jar}"/>
<pathelement location="${qdox.jar}"/>
</path>
<property
name="fortress.collect-meta.classname"
value="org.apache.avalon.fortress.tools.ComponentMetaInfoCollector"/>
<!-- ===================================================================== -->
<!-- Generate or copy fortress meta descriptors -->
<!-- ===================================================================== -->
<target
name="provide-fortress-meta"
description="Add fortress meta descriptors to the compiled classes"
depends="provide-fortress-meta-dynamic, provide-fortress-meta-static"/>
<target
name="provide-fortress-meta-dynamic"
depends="test-fortress-collect-meta-present"
if="avalon-fortress-tools.present">
<taskdef name="fortress-collect-meta"
classname="${fortress.collect-meta.classname}"
classpathref="fortress.tools.classpath"/>
<fortress-collect-meta destdir="${build.classes}">
<fileset dir="${java.dir}"/>
</fortress-collect-meta>
<!-- save it for future use via provide-fortress-meta-static -->
<antcall target="do-save-fortress-meta"/>
</target>
<target
name="provide-fortress-meta-static"
depends="test-fortress-collect-meta-present, complain-fortress-meta-static"
unless="avalon-fortress-tools.present">
<copy todir="${build.classes}">
<fileset dir="${fortress-static-meta.dir}">
<include name="services.list"/>
<include name="META-INF/services/*"/>
<include name="**/*.meta"/>
<include name="**/*.dep"/>
</fileset>
</copy>
</target>
<target name="complain-fortress-meta-static" unless="avalon-fortress-tools.present">
<echo>
.----------------------------------------------------------------.
| HAVE NOT FOUND SOME OF |
| |
| ${avalon-fortress-tools.jar}
| ${qdox.jar}"
|----------------------------------------------------------------|
| Fortress meta info for Excalibur SourceResolving can not |
| be generated dynamically. |
| |
| As a bootrstrap workaround I will use static fortress |
| meta info from |
| |
| ${fortress-static-meta.dir}
| |
| This is okay if you only build Excalibur SourceResolving. |
| |
| If you do any SourceResolving development and espcially if you |
| deal with Fortress meta data in SourceResolving classes please |
| do build or download the jars required for dynamic Fortress |
| meta info generation. |
| |
'----------------------------------------------------------------'
</echo>
</target>
<!-- ===================================================================== -->
<!-- Check if excalibur-fortress-tools.jar and qdox.jar are present -->
<!-- ===================================================================== -->
<target name="test-fortress-collect-meta-present">
<!-- To avoid circular dependency we don't want to build avalon-fortress-tools.jar -->
<!-- We'll also use static meta descriptors if do not find it - so we do not -->
<!-- want to fail the build if do not find it. Hence depchecker.xml not used -->
<!-- currently. -->
<available
classname="${fortress.collect-meta.classname}"
classpathref="fortress.tools.classpath"
property="avalon-fortress-tools.present"/>
</target>
<!-- ===================================================================== -->
<!-- Save generated meta for later static use -->
<!-- by provide-fortress-meta-static -->
<!-- ===================================================================== -->
<!-- ===================================================================== -->
<!-- Because the copy operation is very destructive - we first erase all -->
<!-- existing fortress meta info, we want to make sure that the info has -->
<!-- really been generated. -->
<!-- This is what save-fortress-meta does. It is intended to be invoked -->
<!-- directly from the command line directly, via -->
<!-- ant -f fortress-meta.xml save-fotress-meta. -->
<!-- ===================================================================== -->
<target
name="save-fortress-meta"
description="Copy generated fortress meta back under ./src"
depends="conditionally-save-fortress-meta, complain-save-fortress-meta"/>
<target
name="conditionally-save-fortress-meta"
depends="test-fortress-meta-generated"
if="fortress.meta.generated">
<antcall target="do-save-fortress-meta"/>
</target>
<!-- ===================================================================== -->
<!-- Do copy the generated meta to ${fortress-static-meta.dir} without any -->
<!-- checks. Invoked from conditionally-save-fortress-meta and from -->
<!-- provide-fortress-meta-dynamic. -->
<target name="do-save-fortress-meta">
<!--delete stale meta info-->
<delete dir="${fortress-static-meta.dir}"/>
<mkdir dir="${fortress-static-meta.dir}"/>
<copy todir="${fortress-static-meta.dir}">
<fileset dir="${build.classes}">
<include name="services.list"/>
<include name="META-INF/services/*"/>
<include name="**/*.meta"/>
<include name="**/*.dep"/>
</fileset>
</copy>
</target>
<target name="complain-save-fortress-meta" depends="test-fortress-meta-generated"
unless="fortress.meta.generated">
<echo>
.----------------------------------------------------------------.
| FILE NOT FOUND |
| |
| ${build.classes}/services.list
|----------------------------------------------------------------|
| Fortress meta info has not been generated. |
| |
| ${fortress-static-meta.dir}
| |
| has not been changed. |
'----------------------------------------------------------------'
</echo>
</target>
<target name="test-fortress-meta-generated">
<available
file="${build.classes}/services.list"
property="fortress.meta.generated"/>
</target>
</project>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [Patch] #3 Role2MetaInfoManger update complition and beautification & extension build.xml testcase for collect-meta
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
#3.1 Confirm that Role2MetaInfoManager patch applied completely :-)
BL> Is there a hidden bug this fixes?
Yes, I think there was a hidden bug, a twin of Vjeran's bug,
only to get it one would have to put a full class name into
the config instead of the short one.
#3.2 Confirm that buil.xml testcase patch applied completely :-)
#3.3 Pending **/dag/* patch
AT> Oh, yes, it also adds the dag/* classes to
AT> excalibur-fortress-tools.jar!
BL> Ah, good catch (that was a bug).
:-)
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Patch] #3 Role2MetaInfoManger update complition and beautification
& extension build.xml testcase for collect-meta
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
>
> Here's Patch, let's call it #3
> It completes the update of Role2MetaInfoManager and beautifies and extends
> (a bit) my testcase for <collect-meta> :-)
Ok, no bugs found when I ran it....
> Oh, yes, it also adds the dag/* classes to
> excalibur-fortress-tools.jar!
Ah, good catch (that was a bug).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Patch] #3 Role2MetaInfoManger update complition and beautification & extension build.xml testcase for collect-meta
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
Here's Patch, let's call it #3
It completes the update of Role2MetaInfoManager and beautifies and extends
(a bit) my testcase for <collect-meta> :-)
Oh, yes, it also adds the dag/* classes to
excalibur-fortress-tools.jar!
Only in fortress: build
diff -ru fortress.0/build.xml fortress/build.xml
--- fortress.0/build.xml 2003-05-23 10:43:50.000000000 +0400
+++ fortress/build.xml 2003-05-23 12:21:41.000000000 +0400
@@ -259,7 +259,8 @@
</zipfileset>
<fileset dir="${build.classes}">
<include name="**/util/Service*"/>
- <include name="**/role/Service*"/>
+ <include name="**/role/Service*"/>
+ <include name="**/dag/*"/>
</fileset>
</jar>
</target>
Only in fortress: dist
diff -ru fortress.0/src/java/org/apache/avalon/fortress/impl/role/Role2MetaInfoManager.java fortress/src/java/org/apache/avalon/fortress/impl/role/Role2MetaInfoManager.java
--- fortress.0/src/java/org/apache/avalon/fortress/impl/role/Role2MetaInfoManager.java 2003-05-23 10:43:58.000000000 +0400
+++ fortress/src/java/org/apache/avalon/fortress/impl/role/Role2MetaInfoManager.java 2003-05-23 13:32:05.000000000 +0400
@@ -103,6 +103,15 @@
*/
public MetaInfoEntry getMetaInfoForClassname( final String classname )
{
- return new MetaInfoEntry( m_manager.getRoleForClassname( classname ) );
+ final RoleEntry roleEntry = m_manager.getRoleForClassname( classname );
+
+ if ( roleEntry != null )
+ {
+ return new MetaInfoEntry( roleEntry );
+ }
+ else
+ {
+ return null;
+ }
}
}
diff -ru fortress.0/src/test/org/apache/avalon/fortress/tools/test/build.xml fortress/src/test/org/apache/avalon/fortress/tools/test/build.xml
--- fortress.0/src/test/org/apache/avalon/fortress/tools/test/build.xml 2003-05-22 16:48:14.000000000 +0400
+++ fortress/src/test/org/apache/avalon/fortress/tools/test/build.xml 2003-05-23 13:30:14.000000000 +0400
@@ -1,12 +1,15 @@
<?xml version="1.0"?>
-<project name="Test Excalibur Fortress collect-meta double invocation" default="main">
+<project name="Test Excalibur Fortress collect-meta double invocation"
+ default="test-collect-meta">
<taskdef name="collect-meta"
classname="org.apache.avalon.fortress.tools.ComponentMetaInfoCollector"
classpath="${cp}"/>
- <target name="main">
+ <target name="test-collect-meta"
+ description="test collect-meta; if this task does not fail, the test is passed">
+
<property name="destination"
value="${build.testclasses}/org/apache/avalon/fortress/tools/test"/>
<property name="meta-dir-1"
@@ -14,6 +17,11 @@
<property name="meta-dir-2"
value="${destination}/meta2"/>
+ <!--make sure we do a clean run-->
+ <delete dir="${meta-dir-1}"/>
+ <delete dir="${meta-dir-2}"/>
+
+ <!--create the directory structure-->
<mkdir dir="${meta-dir-1}"/>
<mkdir dir="${meta-dir-2}"/>
@@ -29,6 +37,7 @@
</fileset>
</copy>
+ <!--make sure two subsequent passes do not interfere-->
<collect-meta destdir="${meta-dir-1}">
<fileset dir="${build.testsrc}">
<include name="**/Component1.java"/>
@@ -39,6 +48,14 @@
<include name="**/Component2.java"/>
</fileset>
</collect-meta>
+
+ <!--make sure a second run on the same directory successeeds-->
+ <collect-meta destdir="${meta-dir-1}">
+ <fileset dir="${build.testsrc}">
+ <include name="**/Component1.java"/>
+ </fileset>
+ </collect-meta>
+
</target>
-</project>
\ No newline at end of file
+</project>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Announce] Excalibur Phase III Release Candidate 3 available
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
I'm sorry, Berin, you have to re-present the release candidates
over and over again, but there still seems to be material for
one or two more :-)
This being said I do beleive we can make it a week-to-two-weeks
time frame!
1. Accidentially a part of my patch to Role2InfoManager has
been left out of the last update. Using this opportunity
I also propose to beautify my build.xml testcase for
collect-meta. A patch doing both of these will follow
in an "answer" ot this mail.
2. Berin, here's my reasoning what more may be done
(and why I want it prior to the release)
I beleive FortressRoleManager pollutes user contract of
Fortress: the reality is the user may rely on the fact
that lookup( MetaInfoManager.ROLE ) will return something.
This is guaranteed.
However, currenlty lookup( RoleManager.ROLE ) also ALWAYS
returns something. If users start writing applications
relying on that and if we take RoleManager away later
we may sort of brake backwards compatibility..
Oh, am I talking crap? Most likely users will never do
lookup( RoleManager.ROLE )... only maybe for writing
nested containers...
Anyway this class sort of messes the design.
I have already written that we shall have to add
the Source factories there as well if we want to make
it really usable. And that we may take away everything
except SourceResolve from it (to eliminate runtime-warings
about classes not found)...
So, to be short -- I have made the changes to SourceResolve
project. With my changes
if
* excalibur-fortress-tools.jar
* qdox.jar
are found then the meta info is autogenerated
otherwise
as a workaround statically present in ./src fortress meta
info is present.
But code speaks better then words -- the changes will follow
in another letter.
3. Berin, please also note that those and the same patch
to SourceResolve also adds @avalon.dependency on
SourceFactory to SourceResolverImpl.java
I beleive you will want this change too.
4. Berin, please note that for some reason
excalibur-fortress-tools.jar/<collect-meta>
does not generate .deps for me.
It does not generate them for my own project and
it does not generate them in the modified sourceresolve
project
- WBR, Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Patch] #5
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Berin!
One point in one of our discussions has pushed me to check this --
and so:
--- DefaultContainerManager.orig 2003-05-23 10:43:54.000000000 +0400
+++ DefaultContainerManager.java 2003-05-23 19:01:04.000000000 +0400
@@ -203,11 +203,13 @@
try
{
+ final Context implContext = m_contextManager.getChildContext();
+
ContainerUtil.enableLogging( instance, m_logger );
- ContainerUtil.contextualize( instance, managerContext );
+ ContainerUtil.contextualize( instance, implContext );
final ServiceManager serviceManager =
- createServiceManager( managerContext );
+ createServiceManager( implContext );
ContainerUtil.service( instance, serviceManager );
WBR, Anton :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Fortress] [PATCH] [Vjeran's problem]
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
Vjeran Marcinko <ma...@jware.net> has reported an error I have seen
myself and here's an excerpt from his message and a fix
VM> I cannot notice any changes in .xconf or .roles file format,
VM> but my fortress app doesn't work anymore...
VM>
VM> Caused by: java.lang.NullPointerException: "roleEntry" cannot be null.
VM> at org.apache.avalon.fortress.MetaInfoEntry.<init>(MetaInfoEntry.java:121)
VM> at org.apache.avalon.fortress.impl.role.Role2MetaInfoManager.getMetaInfoForShortName(Role2MetaInfoManager.java:82)
--- Role2MetaInfoManager.orig 2003-04-21 22:34:54.000000000 +0400
+++ Role2MetaInfoManager.java 2003-05-22 11:07:34.000000000 +0400
@@ -79,7 +79,17 @@
*/
public MetaInfoEntry getMetaInfoForShortName( final String shortname )
{
- return new MetaInfoEntry( m_manager.getRoleForShortName( shortname ) );
+ final RoleEntry roleEntry = m_manager.getRoleForShortName( shortname );
+
+ if ( roleEntry != null )
+ {
+ return new MetaInfoEntry( roleEntry );
+ }
+ else
+ {
+ return null;
+ }
+
}
/**
@@ -94,6 +104,16 @@
*/
public MetaInfoEntry getMetaInfoForClassname( final String classname )
{
- return new MetaInfoEntry( m_manager.getRoleForClassname( classname ) );
+ final RoleEntry roleEntry = m_manager.getRoleForClassname( classname );
+
+ if ( roleEntry != null )
+ {
+ return new MetaInfoEntry( roleEntry );
+ }
+ else
+ {
+ return null;
+ }
+
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org