cvs commit: avalon-excalibur/compatibility/src/test/org/apache/avalon/excalibur/concurrent/test ReadWriteLockTestCase.java

leosutic2003/03/31 23:34:36 Modified:compatibility/src/test/org/apache/avalon/excalibur/concurrent/test ReadWriteLockTestCase.java Log: Another attempt. Removed the debugging code from previous commit and attempted to eliminate the race condition that caused

cvs commit: avalon-excalibur/compatibility/src/java/org/apache/avalon/excalibur/concurrent ReadWriteLock.java

leosutic2003/03/31 23:33:59 Modified:compatibility/src/java/org/apache/avalon/excalibur/concurrent ReadWriteLock.java Log: Another attempt. Removed the debugging code from previous commit. Revision ChangesPath 1.6 +1 -3 avalon-excalibur

RE: [VOTE] Release Excalibur Components Phase II, Release candidate 2

Give me a day to fix the gump problem with concurrent. Then I'll vote +1. /LS > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > > I received virtually no objections from release candidate 1, > so my assumption is that everything should be ok. I propose > that we release this set of compone

[PATCH] Fortress read config with file protocol

Attached is the patch. Is this necessary to add a test case? an example? Maybe we can rely on SourceResolver's tests. A+. Didier. Index: ContextManager.java === RCS file: /home/cvspublic/avalon-excalibur/fortress/src/java/org/apache/a

Re: Release Phoenix 4.0.4 ?

On Monday, March 31, 2003, at 03:06 PM, Paul Hammant wrote: Can we? Has been in beta for ages. +1 -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Release Phoenix 4.0.4 ?

Can we? Has been in beta for ages. - Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Release Excalibur Phase II, release candidate 2

I have not heard any issues raised regarding the last set of components, please place your votes or voice your concerns. +1 from me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-cli/src/java Merlin.java

bloritsch2003/03/31 11:04:20 Modified:datasource/src/test/org/apache/excalibur/datasource/impl/test SimpleDataSourceManagerTest.java merlin/merlin-cli/src/java Merlin.java Log: commenting out unused code Revision ChangesPath 1.3

cvs commit: avalon-sandbox/merlin/merlin-core/src/java/org/apache/avalon/merlin/block/impl DefaultBlock.java

bloritsch2003/03/31 10:52:22 Modified:merlin/assembly/src/java/org/apache/avalon/assembly/appliance DefaultAppliance.java merlin/assembly/src/test/org/apache/avalon/playground ComplexComponent.java SimpleComponent.java

[VOTE] Release Excalibur Components Phase II, Release candidate 2

I received virtually no objections from release candidate 1, so my assumption is that everything should be ok. I propose that we release this set of components RSN. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional co

cvs commit: avalon-excalibur/datasource/src/java/org/apache/avalon/excalibur/datasource JdbcConnectionPool.java ResourceLimitingJdbcDataSource.java

bloritsch2003/03/31 10:32:55 Modified:datasource build.xml default.properties datasource/src/java/org/apache/avalon/excalibur/datasource JdbcConnectionPool.java ResourceLimitingJdbcDataSource.java Log: I can't get HSQL to

Re: excalibur-compatibility deadlock problem

Leo Simons wrote: nope! I've tried it on a couple of machines, and a normal 'ant test' doesn't result in failure, whereas running GUMP (either completely or using '/data/gump/bin/build excalibur-compatibility', which just rebuilds the excalibur-compatibility project and nothing else) does resul

Re: ftp server

On Monday, March 31, 2003, at 11:40 AM, Jason van Zyl wrote: Is there a mailing list specifically for the ftpserver now or just the general incubator list? I have a few questions :-) [EMAIL PROTECTED] is it i believe. just a general free-for-all. -pete ---

ftp server

Howdy, Is there a mailing list specifically for the ftpserver now or just the general incubator list? I have a few questions :-) -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his

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

bloritsch2003/03/31 08:23:14 Modified:datasource build.xml default.properties Log: fix a typo for starting the server Revision ChangesPath 1.42 +40 -20avalon-excalibur/datasource/build.xml Index: build.xml ==

cvs commit: avalon-excalibur/datasource build.xml

bloritsch2003/03/31 08:03:17 Modified:datasource build.xml Log: fix a typo for starting the server Revision ChangesPath 1.41 +1 -1 avalon-excalibur/datasource/build.xml Index: build.xml ===

cvs commit: avalon-excalibur/lib junitperf.LICENSE.txt junitperf.jar

bloritsch2003/03/31 07:58:45 Added: lib junitperf.LICENSE.txt junitperf.jar Log: move junitperf here Revision ChangesPath 1.1 avalon-excalibur/lib/junitperf.LICENSE.txt Index: junitperf.LICENSE.txt ===

cvs commit: avalon-excalibur/thread/lib junitperf.LICENSE.txt junitperf.jar

bloritsch2003/03/31 07:52:55 Modified:thread build.xml default.properties Removed: thread/lib junitperf.LICENSE.txt junitperf.jar Log: fix some errors Revision ChangesPath 1.33 +2 -1 avalon-excalibur/thread/build.xml Index: build.xml =

Re: Logger configuration in Fortress

Schaible, Jörg wrote: Hi Berin, after some tasks with higher priority I am back at the logger. I switched also the list. Berin Loritsch wrote: I recently made an alteration to Fortress (about a week ago) that altered the way it decided what the root category was going to be. Previously, it

cvs commit: avalon-excalibur/monitor default.properties

bloritsch2003/03/31 07:34:45 Modified:monitor default.properties Log: update the build Revision ChangesPath 1.19 +2 -2 avalon-excalibur/monitor/default.properties Index: default.properties =

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

bloritsch2003/03/31 07:31:26 Modified:eventbuild.xml default.properties Log: update the build for excalibur event Revision ChangesPath 1.46 +3 -9 avalon-excalibur/event/build.xml Index: build.xml ===

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

bloritsch2003/03/31 07:25:50 Modified:pool build.xml default.properties Log: update pool build so that it uses util.concurrent Revision ChangesPath 1.34 +1 -0 avalon-excalibur/pool/build.xml Index: build.xml ===

cvs commit: avalon-excalibur/configuration/lib LICENSE.isorelax.txt LICENSE.jing.txt isorelax.jar jing.jar

bloritsch2003/03/31 07:17:08 Modified:configuration default.properties Removed: configuration/lib LICENSE.isorelax.txt LICENSE.jing.txt isorelax.jar jing.jar Log: update build to find the new location for the jar files Revision ChangesPath 1.

cvs commit: avalon-excalibur/lib LICENSE.isorelax.txt LICENSE.jing.txt LICENSE.qdox.txt isorelax.jar jing.jar

bloritsch2003/03/31 07:16:25 Added: lib LICENSE.isorelax.txt LICENSE.jing.txt LICENSE.qdox.txt isorelax.jar jing.jar Log: adding LICENSE files and jar files Revision ChangesPath 1.1 avalon-excalibur/lib/LICENSE.isorelax.txt

Re: [GUMP] Build Failure - Cocoon

Stefano Mazzocchi wrote: > > > Did anybody touch the excalibur/source stuff recently? Ok. I reverted enough of the other day's commit so that Cocoon will compile in GUMP. It is better to use accessors for field access, since that reduces the likelihood of compilation problems when we refactor th

Re: [GUMP] Build Failure - Cocoon

Stefano Mazzocchi wrote: > [EMAIL PROTECTED] wrote: > > > Did anybody touch the excalibur/source stuff recently? > > Stefano. > Yes I did, I provided some wrappers methods to set values/ read values so that you don't work with the fields any more. I can revert the names of the fields for the time

Re: excalibur-compatibility deadlock problem

Leo Simons wrote: > http://lsd.student.utwente.nl/gump/excalibur-compatibility.html: > > [junit] Testcase: testDeadLock took 0.328 sec > [junit] FAILED > [junit] null > [junit] junit.framework.AssertionFailedError > [junit] at org.apache.avalon.excalibur.concurrent.test.ReadWriteLockTestCase.test

Re: [Vote] Sevak refactor

On Sunday, March 30, 2003, at 02:50 PM, Paul Hammant wrote: An API, and three servlet container implementations (Catalina, Jo! and Jetty). Mavenification (as a further experiment) is thought to be a good idea too. Here is my +1 +1 About Maven, as long as it deals with a released version, I'm

cvs commit: avalon-excalibur/monitor/src/java/org/apache/avalon/excalibur/monitor MonitorableURLSource.java

bloritsch2003/03/31 06:24:43 Modified:monitor/src/java/org/apache/avalon/excalibur/monitor MonitorableURLSource.java Log: use the accessor, not the file field Revision ChangesPath 1.11 +3 -3 avalon-excalibur/monitor/src/java/org/apache/a

cvs commit: avalon-excalibur/sourceresolve/src/test/org/apache/excalibur/source SourceResolverImplTestCase.java

bloritsch2003/03/31 06:24:20 Modified:sourceresolve/src/test/org/apache/excalibur/source SourceResolverImplTestCase.java Log: remove statement that is no longer true Revision ChangesPath 1.5 +0 -2 avalon-excalibur/sourceresolve/src/test

cvs commit: avalon-excalibur/sourceresolve/src/java/org/apache/excalibur/source/impl FileSource.java URLSource.java

bloritsch2003/03/31 06:21:42 Modified:sourceresolve/src/java/org/apache/excalibur/source/impl FileSource.java URLSource.java Log: revert the m_file variable change, add an accessor, and deprecate the name of the file variable so that users will move to the ac

Re: [GUMP] Build Failure - Cocoon

[EMAIL PROTECTED] wrote: compile-core: [copy] Copying 41 files to /home/rubys/jakarta/cocoon-2.1/build/cocoon-20030331/classes [copy] Copied 37 empty directories to /home/rubys/jakarta/cocoon-2.1/build/cocoon-20030331/classes [javac] Compiling 1 source file to /home/rubys/jakarta

Logger configuration in Fortress

Hi Berin, after some tasks with higher priority I am back at the logger. I switched also the list. Berin Loritsch wrote: > I recently made an alteration to Fortress (about a week ago) that > altered the way it decided what the root category was going to be. > Previously, it assigned the root cat

RE: excalibur-compatibility deadlock problem

> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > > Leo Sutic wrote: > > If you run "ant test" on the compatibility project (and not GUMP, > > which you seem to be running), do you still get a failure there? > > nope! I've tried it on a couple of machines, and a normal 'ant test

cvs commit: avalon-excalibur/compatibility/src/test/org/apache/avalon/excalibur/concurrent/test ReadWriteLockTestCase.java

leosutic2003/03/31 03:42:53 Modified:compatibility/src/test/org/apache/avalon/excalibur/concurrent/test ReadWriteLockTestCase.java Log: Inserted some debugging code to see why GUMP fails. The test failures can not be duplicated outside of GUMP. Revision

cvs commit: avalon-excalibur/compatibility/src/java/org/apache/avalon/excalibur/concurrent ReadWriteLock.java

leosutic2003/03/31 03:42:03 Modified:compatibility/src/java/org/apache/avalon/excalibur/concurrent ReadWriteLock.java Log: Inserted some debugging code to see why GUMP fails. The test failures can not be duplicated outside of GUMP. Revision Changes

Re: excalibur-compatibility deadlock problem

Leo Sutic wrote: From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons is this a known issue? No, it's not. I am unable to duplicate that error. You seem to have problems with many testcases that involve multiple threads. the failure with the monitor thing was on a different machine, diffe

[GUMP] Build Failure - incubator-altrmi

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

[GUMP] Build Failure - excalibur-compatibility

opying 1 file to /home/rubys/jakarta/avalon-excalibur/compatibility/build/conf jar: [mkdir] Created dir: /home/rubys/jakarta/avalon-excalibur/compatibility/build/lib [jar] Building jar: /home/rubys/jakarta/avalon-excalibur/compatibility/build/lib/excalibur-compatibility-20030331.jar di

RE: excalibur-compatibility deadlock problem

> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > > is this a known issue? No, it's not. I am unable to duplicate that error. You seem to have problems with many testcases that involve multiple threads. If you run "ant test" on the compatibility project (and not GUMP, which you s

excalibur-compatibility deadlock problem

http://lsd.student.utwente.nl/gump/excalibur-compatibility.html: [junit] Testcase: testDeadLock took 0.328 sec [junit] FAILED [junit] null [junit] junit.framework.AssertionFailedError [junit] at org.apache.avalon.excalibur.concurrent.test.ReadWriteLockTestCase.testDeadLock(ReadWriteLockTestCase.j