Re: [GUMP] Build Failure - avalon-phoenix

Berin Loritsch wrote: Gump Integration Build wrote: check-cli-init: check-cli: [echo] ** [echo] * Please execute target * [echo] * 'get-cli' in the main * [echo] * build.xml build file * [echo] * to download one and* [echo] * a half Mb

cvs commit: avalon-phoenix/src/java/org/apache/avalon/phoenix/components/manager MX4JSystemManager.java

bloritsch2003/06/03 06:03:39 Modified:.build.xml src/java/org/apache/avalon/phoenix/components/manager MX4JSystemManager.java Log: remove spice CLI references Revision ChangesPath 1.251 +2 -39 avalon-phoenix/build.xml

Re: thread safety of BCELWrapperGenerator?

Neeme Praks wrote: Question: is BCELWrapperGenerator supposed to be thread safe? Especially .createWrapper(Class) method invocations? I'm getting some weird errors from BCEL, from time to time, not always... So I was wondering... looking at the source, it is quite clear that it is not thread saf

Re: [GUMP] Build Failure - excalibur-monitor

To all of these, I think I have it fixed--but we will have to wait until the next gump run to find out. Gump Integration Build wrote: This email is autogenerated from the output from:

Re: [GUMP] Build Failure - avalon-phoenix

Gump Integration Build wrote: check-cli-init: check-cli: [echo] ** [echo] * Please execute target * [echo] * 'get-cli' in the main * [echo] * build.xml build file * [echo] * to download one and* [echo] * a half Mb of Spice CLI * [

thread safety of BCELWrapperGenerator?

Question: is BCELWrapperGenerator supposed to be thread safe? Especially .createWrapper(Class) method invocations? I'm getting some weird errors from BCEL, from time to time, not always... So I was wondering... looking at the source, it is quite clear that it is not thread safe (usage of m_class

[GUMP] PRE-REQ FAILED for phoenix-example-testserver

This email is autogenerated from the output from: Missing prereq /home/rubys/jakarta/avalon-cornerstone/build/lib

[GUMP] PRE-REQ FAILED for phoenix-example-pdk

This email is autogenerated from the output from: Missing prereq /home/rubys/jakarta/avalon-phoenix/target/lib/phoenix-p

[GUMP] PRE-REQ FAILED for phoenix-example-demo

This email is autogenerated from the output from: Missing prereq /home/rubys/jakarta/avalon-cornerstone/build/lib/corne

[GUMP] Build Failure - excalibur-monitor

This email is autogenerated from the output from: Buildfile: build.xml Caught exception (org.apache.tools.ant.BuildExcepti

[GUMP] Build Failure - avalon-phoenix

This email is autogenerated from the output from: Buildfile: build.xml init-windows-nt: init-windows-2000: init-windows-xp

[GUMP] Build Failure - excalibur-datasource

This email is autogenerated from the output from: Buildfile: build.xml Caught exception (org.apache.tools.ant.BuildExce

[GUMP] Build Failure - excalibur-store

This email is autogenerated from the output from: Buildfile: build.xml Caught exception (org.apache.tools.ant.BuildException

Re: Fortress: BCEL llibrary problem

There was also a related issue (related to hibernate and jboss) with the Respository.lookupClass approach and I replaced it with a more embeddable-friendly approach couple of days ago. No more static methods... ;-) Rgds, Neeme Peter Severin wrote: Hi all, I am progressing with less and less p

ServiceManager for life-cycle extensions

Berin and others, Used to be that life-cycle extentions got introduced to Fortress in the container's initialize() method. Now, I've found, the LifeCycleExtensionManager is provided in the container-manager context. The problem is that the create(...) method of my extension needs a ServiceMan

Re: Excalibur I18N

On Tue, 3 Jun 2003 12:31 am, Berin Loritsch wrote: > The only code in the Excalibur set that really *uses* Excalibur i18n > is Excalibur Logger. I understand that it is in use with both Merlin > and Phoenix. Is that still true? In Phoenix it is still true. I believe some of the code may have bee

Re: cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/commandTPCThreadManager.xinfo ThreadManager.java

Peter Royal wrote: On Monday, June 2, 2003, at 04:22 PM, Berin Loritsch wrote: Is this the Phoenix metadata format for components? yup. If so, could you add them for Monitor, SourceResolve, DataSource, Store and XMLUtil? That would increase our abilities to interoperate. I can add for the on

Re: cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPCThreadManager.xinfo ThreadManager.java

On Monday, June 2, 2003, at 04:22 PM, Berin Loritsch wrote: Is this the Phoenix metadata format for components? yup. If so, could you add them for Monitor, SourceResolve, DataSource, Store and XMLUtil? That would increase our abilities to interoperate. I can add for the ones where it makes sense.

Re: cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/commandTPCThreadManager.xinfo ThreadManager.java

[EMAIL PROTECTED] wrote: proyal 2003/06/02 13:18:04 1.1 avalon-excalibur/event/src/java/org/apache/excalibur/event/command/TPCThreadManager.xinfo Index: TPCThreadManager.xinfo === http://jakarta

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPCThreadManager.xinfo ThreadManager.java

proyal 2003/06/02 13:18:04 Modified:event/src/java/org/apache/excalibur/event/command ThreadManager.java Added: event/src/java/org/apache/excalibur/event/command TPCThreadManager.xinfo Log: * Add ROLE to ThreadManager * xinfo

Merlin Roles

Hi, I have a case where two components implement a service. Another service is dependent on both components through different roles. Right now merlin only applies one of the components to both roles. How do I configure them so that each role is mapped to the correct component? Rodney Riven

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command AbstractThreadManager.java

proyal 2003/06/02 12:26:35 Modified:event/src/java/org/apache/excalibur/event/command AbstractThreadManager.java Log: update javadocs Revision ChangesPath 1.21 +2 -2 avalon-excalibur/event/src/java/org/apache/excalibur/event/command/Abs

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPCThreadManager.java

proyal 2003/06/02 12:26:10 Modified:event/src/java/org/apache/excalibur/event/command TPCThreadManager.java Log: Update javadocs Revision ChangesPath 1.40 +3 -3 avalon-excalibur/event/src/java/org/apache/excalibur/event/command/TPCThrea

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPCThreadManager.java

proyal 2003/06/02 12:16:34 Modified:event/src/java/org/apache/excalibur/event/command TPCThreadManager.java Log: Remove unused field and parameter Revision ChangesPath 1.39 +0 -2 avalon-excalibur/event/src/java/org/apache/excalibur/even

cvs commit: avalon-excalibur maven-common.xml

leosimons2003/06/02 12:08:06 Modified:.maven-common.xml Log: postGoal does not support description attribute Revision ChangesPath 1.4 +2 -3 avalon-excalibur/maven-common.xml Index: maven-common.xml

Re: [Announce] Excalibur Release Phase III, RC 4

Berin, Thanks, I'll give this a whirl shortly. Shash Berin Loritsch wrote: Berin Loritsch wrote: I have created Release Candidate 4 for Excalibur components. This includes the latest and greatest for Fortress. I believe that we have a winner here, and if there are no BUG reports in the next da

Re: [Announce] Excalibur Release Phase III, RC 4

Berin Loritsch wrote: I have created Release Candidate 4 for Excalibur components. This includes the latest and greatest for Fortress. I believe that we have a winner here, and if there are no BUG reports in the next day or two, we will vote to release it. Minor updates: I added Event to include

cvs commit: avalon-excalibur/monitor default.properties

bloritsch2003/06/02 11:37:41 Modified:sourceresolve default.properties .libraries.properties monitor default.properties Log: Update the version numbers so that the new version reflects the meta info. Revision ChangesPath 1.14 +3

cvs commit: avalon-excalibur/event default.properties

bloritsch2003/06/02 11:28:55 Modified:datasource/src/java/org/apache/avalon/excalibur/datasource/cluster AbstractDataSourceCluster.java .libraries.properties eventdefault.properties Log: Update the AbstractDataSourceCl

Re: [Announce] Excalibur Release Phase III, RC 4

Shash Chatterjee wrote: Berin, Berin Loritsch wrote: I have created Release Candidate 4 for Excalibur components. This includes the latest and greatest for Fortress. I believe that we have a winner here, and if there are no BUG reports in the next day or two, we will vote to release it. Looks

Re: [Announce] Excalibur Release Phase III, RC 4

Berin, Berin Loritsch wrote: I have created Release Candidate 4 for Excalibur components. This includes the latest and greatest for Fortress. I believe that we have a winner here, and if there are no BUG reports in the next day or two, we will vote to release it. Looks like Event needs a release

[Announce] Excalibur Release Phase III, RC 4

I have created Release Candidate 4 for Excalibur components. This includes the latest and greatest for Fortress. I believe that we have a winner here, and if there are no BUG reports in the next day or two, we will vote to release it. ---

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/util ContextManager.java

bloritsch2003/06/02 07:44:48 Modified:datasource build.xml fortress/src/java/org/apache/avalon/fortress/impl/factory BCELWrapperGenerator.java fortress/src/java/org/apache/avalon/fortress/util ContextManager.ja

cvs commit: avalon-excalibur/logger/src/java/org/apache/avalon/excalibur/logger SimpleLogKitManager.java

bloritsch2003/06/02 07:35:22 Modified:logger/src/java/org/apache/avalon/excalibur/logger SimpleLogKitManager.java Log: remove the TODO item in Logger Revision ChangesPath 1.7 +2 -3 avalon-excalibur/logger/src/java/org/apache/avalon/exca

Excalibur I18N

It appears Excalibur I18N is used by Excalibur Logger, which poses a requirement to include the JAR as a dependency for both Fortress and ECM. Also because the components (DataSource, Monitor, SourceResolve, Store, XMLUtil) use the ECM TestCase, they also have a test time dependency on I18N. The o

cvs commit: avalon-excalibur/monitor build.xml

bloritsch2003/06/02 07:19:30 Modified:monitor build.xml Log: adding 18n back in for testing Revision ChangesPath 1.40 +1 -0 avalon-excalibur/monitor/build.xml Index: build.xml === RCS file

cvs commit: avalon-excalibur/xmlutil build.xml

bloritsch2003/06/02 07:17:54 Modified:xmlutil build.xml Log: add i18n JAR back in for testing Revision ChangesPath 1.46 +1 -0 avalon-excalibur/xmlutil/build.xml Index: build.xml === RCS fi

cvs commit: avalon-excalibur/monitor build.xml default.properties

bloritsch2003/06/02 07:12:03 Modified:datasource default.properties build.xml fortress build.xml xmlutil default.properties build.xml monitor build.xml default.properties Log: Reference i18n only where it is truly needed. Revision

cvs commit: avalon-excalibur/logger/src/java/org/apache/avalon/excalibur/logger DefaultLogTargetFactoryManager.java

bloritsch2003/06/02 06:53:33 Modified:logger/src/java/org/apache/avalon/excalibur/logger DefaultLogTargetFactoryManager.java Log: simplify the context stuff Revision ChangesPath 1.12 +5 -22 avalon-excalibur/logger/src/java/org/apache/aval