DO NOT REPLY [Bug 31286] - [logging] Memory leaks in JBoss due to LogFactory cache

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31286





--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 08:37 ---
Created an attachment (id=14501)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14501&action=view)
Further tests for memory leak

The patch includes a new class -- a special classloader that may also be useful
in tests of the JCL discovery process.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31286] - [logging] Memory leaks in JBoss due to LogFactory cache

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31286


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 08:34 ---
As discussed on the commons-dev list, even using WeakHashtable the classloader
is not released when LogFactoryImpl is loaded by a parent loader and the
Log wrapper is loaded  by a child.  This is because the LogFactoryImpl holds a
reference to the Log in its instances map, and that reference prevents the Log's
classloader being released.

Will attach a patch to the JUnit tests that show the problem.  Sadly, no fix is
in the patch :(

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [chain] steps towards 1.0.1 release?

[Craig McClanahan]

I'm fine with a 1.1 designation (there is a quite useful enhancement
here) and will review the code and docs tomorrow for any useful
updates.

Craig


On Wed, 16 Mar 2005 22:29:42 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Feb 2005 22:30:28 -0600, Joe Germuska
> <[EMAIL PROTECTED]> wrote:
> > So, as we move towards a Struts 1.3.0 release depending on
> > commons-chain, it seems that it would be nice to get a minor release
> > of commons-chain to go with it.  It would be nice for Struts to be
> > able to support the compound String representation of a
> > catalog/command combination, and I would like to be able to use the
> > (just-committed) change to LookupCommand which allows you to ignore a
> > "true" returned from a looked up command.
> >
> > Is there anything else people would want to see in a minor release?
> > Any reason to choose any version number other than 1.0.1?
> >
> > Since I'm agitating, I should volunteer to be the release manager.
> > I've never done it before, so it'll take me a little time to go
> > through the whole routine, etc.  I'd happily let anyone else do it if
> > they like, but it seems to be one of those chores that people don't
> > love to take on.
> 
> (Resurrecting this thread...)
> 
> I don't have a problem with doing the mechanics of the release, if
> other folks are willing to pitch in to get the code and docs in shape.
> I think I agree with Simon that 1.1 might be a better designation than
> 1.0.1.
> 
> --
> Martin Cooper
> 
> 
> > Joe
> >
> > --
> > --
> > Joe Germuska
> > Vice President, Software Development
> > JGSullivan Interactive, Inc.
> > [EMAIL PROTECTED] 312/475-2488 (v)312/943-9675 (f)
> > [EMAIL PROTECTED]  312/404-3783 (m)
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration]Site update of howtos

[Oliver Heger]

This sounds interesting. Maybe it is possible to tell maven to use a 
version depending sub directory for the deployment (i.e. 
commons/configuration/)?

One problem that I see has to do with dealing with changes at 
commons-build. What if the styles or menu structures change? Do we then 
have to regenerate the old docs to reflect these changes?

Oliver
Eric Pugh wrote:
Over in Turbine land we have the advantage of a separate turbine-site
project.   We have generic site doucmentation, and then the maven
generated docs seperated by version:
/ generic site docs
/2.3
/2.3.1
/2.4-M1
And so on.
What we could do is have 
/commons/configuration/  <- current site docs symlinked to
/commons/configuration/1.0
/commons/configuration/1.1/ <-- new site docs
/commons/configuration/1.0/ <-- old site docs

And provide a link to the 1.1 and 1.0 from both projects
Eric
-Original Message-
From: Oliver Heger [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 15, 2005 8:28 PM
To: Jakarta Commons Developer List
Subject: [configuration]Site update of howtos

Our current site seems to be very confusing for our users as can be seen
in multiple postings on the user list. The main reason is probably the 
user guide (the howtos), which describes the latest version in SVN 
rather than the 1.0 release, which is used by most users.

I have now applied a quick and dirty fix for this situation: I manually 
uploaded the 1.0 howtos on the server. Then I created two index pages 
for the old and new howtos and linked to them in the main navigation 
bar, analogous as for the API docs. In the index page for the SVN howtos

there is an explicit warning that this may not be compatible with the 
latest released version.

This is of course only a temporary solution because it requires manual 
processing on the server. I don't know how we should deal with this 
problem. Would it make sense to store both the old and new howtos in the

xdocs and let maven generate it all? I guess that would be the easiest
way.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
Dipl.-Inform. Oliver Heger
Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren
Klinikum der Philipps-Universität Marburg
Baldingerstraße,
D-35037 Marburg
Tel: +49 6421 28-66923
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [chain] steps towards 1.0.1 release?

[Martin Cooper]

On Tue, 22 Feb 2005 22:30:28 -0600, Joe Germuska
<[EMAIL PROTECTED]> wrote:
> So, as we move towards a Struts 1.3.0 release depending on
> commons-chain, it seems that it would be nice to get a minor release
> of commons-chain to go with it.  It would be nice for Struts to be
> able to support the compound String representation of a
> catalog/command combination, and I would like to be able to use the
> (just-committed) change to LookupCommand which allows you to ignore a
> "true" returned from a looked up command.
> 
> Is there anything else people would want to see in a minor release?
> Any reason to choose any version number other than 1.0.1?
> 
> Since I'm agitating, I should volunteer to be the release manager.
> I've never done it before, so it'll take me a little time to go
> through the whole routine, etc.  I'd happily let anyone else do it if
> they like, but it seems to be one of those chores that people don't
> love to take on.

(Resurrecting this thread...)

I don't have a problem with doing the mechanics of the release, if
other folks are willing to pitch in to get the code and docs in shape.
I think I agree with Simon that 1.1 might be a better designation than
1.0.1.

--
Martin Cooper


> Joe
> 
> --
> --
> Joe Germuska
> Vice President, Software Development
> JGSullivan Interactive, Inc.
> [EMAIL PROTECTED] 312/475-2488 (v)312/943-9675 (f)
> [EMAIL PROTECTED]  312/404-3783 (m)
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [beanutils] [logging]j2ee unit tests added: memory leak demonstrated (?)

[Brian Stansberry]

--- Simon Kitching <[EMAIL PROTECTED]> wrote:

> 
> I should have been a little clearer about
> MemoryTestCase.
> There are two tests that are failing:
> 
> * testComponentRegistersCustomConverter
> This fails for a reasonably obvious reason, and it's
> the same one that is already documented in the
> javadoc
> for JCL's WeakHashtable class. Unfortunately as this
> test shows, it will be encountered quite often when
> people use beanutils converter functionality in a
> j2ee-like environment.
> 
> * testComponentRegistersStandardConverter
> This fails for no reason I can understand. It is
> very similar
> to testComponentRegistersCustomConverter except that
> it does
> not involve loading a class via a child classloader,
> and
> therefore should not trigger the bug I believe
> exists. 
> 
> And yes, commending out the reference to
> FloatConverter in the 
> testComponentRegistersStandardConverter test does
> make it pass;
> the million-dollar question is: why does the test
> fail when
> FloatConverter is used? Maybe it's because when
> running 
> "maven test", the unit test code is actually run
> within a
> custom classloader? Does maven itself use BeanUtils?
> Hmm..
> 

Ahh, I had run the tests inside Eclipse, and
testComponentRegistersStandardConverter passed.

Could very well be due to maven (which I know very
little about).  

Just to add further confusion, I added a target to the
beanutils build.xml to run the MemoryTestCase, and
testComponentRegistersStandardConverter failed.

I threw in a System.out.println to record the
classname of origContextClassLoader; in Eclipse it's
sun.misc.Launcher$AppClassLoader; in both maven and
ant it's org.apache.tools.ant.loader.AntClassLoader.

Brian



__ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] is setting context classloader correctly mandated by J2EE container specifications?

[Tim Reilly]

Simon Kitching wrote:
> I'm wondering if we need to provide a configurable "Singleton strategy"
> that the user of the library can set. We would provide a default
> "singleton strategy" but users could override that if the default
> behaviour doesn't result in correct Singleton behaviour.
> 

I think it's a good idea (my 2 cents)

-TR

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r157874 - in jakarta/commons/proper/math/trunk: src/java/org/apache/commons/math/distribution/ src/test/org/apache/commons/math/distribution/ xdocs/ xdocs/userguide/

[brentworden]

Author: brentworden
Date: Wed Mar 16 19:20:12 2005
New Revision: 157874

URL: http://svn.apache.org/viewcvs?view=rev&rev=157874
Log:
added weibull distribution

Added:

jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/WeibullDistribution.java

jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/WeibullDistributionImpl.java

jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/distribution/WeibullDistributionTest.java
Modified:

jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/CauchyDistributionImpl.java

jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/DistributionFactory.java

jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/distribution/DistributionFactoryImplTest.java
jakarta/commons/proper/math/trunk/xdocs/changes.xml
jakarta/commons/proper/math/trunk/xdocs/userguide/distribution.xml

Modified: 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/CauchyDistributionImpl.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/CauchyDistributionImpl.java?view=diff&r1=157873&r2=157874
==
--- 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/CauchyDistributionImpl.java
 (original)
+++ 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/CauchyDistributionImpl.java
 Wed Mar 16 19:20:12 2005
@@ -22,7 +22,7 @@
  * Default implementation of
  * [EMAIL PROTECTED] org.apache.commons.math.distribution.CauchyDistribution}.
  *
- * @version $Revision$ $Date$
+ * @version $Revision: 1.13 $ $Date$
  */
 public class CauchyDistributionImpl extends AbstractContinuousDistribution 
implements CauchyDistribution, Serializable {
@@ -37,8 +37,8 @@
private double scale = 1;
 
/**
-* Creates normal distribution with the mean equal to zero and standard
-* deviation equal to one. 
+* Creates cauchy distribution with the medain equal to zero and scale
+* equal to one. 
 */
public CauchyDistributionImpl(){
this(0.0, 1.0);

Modified: 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/DistributionFactory.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/DistributionFactory.java?view=diff&r1=157873&r2=157874
==
--- 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/DistributionFactory.java
 (original)
+++ 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/DistributionFactory.java
 Wed Mar 16 19:20:12 2005
@@ -32,6 +32,7 @@
  * Poisson
  * Normal
  * Student's t
+ * Weibull
  * 
  *
  * Common usage:
@@ -175,8 +176,22 @@
  * Create a new Poisson distribution with poisson parameter lambda.
  * 
  * @param lambda poisson parameter
- * @return a new normal distribution.  
+ * @return a new poisson distribution.  
  */   
 public abstract PoissonDistribution 
 createPoissonDistribution(double lambda);
+
+/**
+ * Create a new Weibull distribution with the given shape and scale
+ * parameters.
+ * 
+ * @param alpha the shape parameter.
+ * @param beta the scale parameter.
+ * @return a new Weibull distribution.  
+ */   
+public WeibullDistribution createWeibullDistribution(
+double alpha, double beta)
+{
+return new WeibullDistributionImpl(alpha, beta);
+}
 }

Added: 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/WeibullDistribution.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/WeibullDistribution.java?view=auto&rev=157874
==
--- 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/WeibullDistribution.java
 (added)
+++ 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/WeibullDistribution.java
 Wed Mar 16 19:20:12 2005
@@ -0,0 +1,63 @@
+/*
+ * Copyright 2005 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

Re: Tomcat 5 shutdown issue with jsvc commons daemon

[Bernard]

Thanks Wolfgang!
Sorry about my previous email - I found my mistake.

Regards,

Bernard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5 shutdown issue with jsvc commons daemon

[Bernard]

Thanks Wolfgang!

Still problems.

I downloaded from
http://cvs.apache.org/builds/jakarta-commons/nightly/commons-daemon/
the latest file:
commons-daemon-20050316.zip

autoconf worked fine.
./configure worked fine.
make failed with many errors.

How to fix this? Is it worth it? When is the next version coming out?

The errors are below.
I cross-posted to the commons-dev list because I used a nightly build.

Many thanks,

Bernard


# ./configure
*** Current host ***
checking build system type... i586-pc-linux-gnu
checking host system type... i586-pc-linux-gnu
checking cached host system type... ok
*** C-Language compilation tools ***
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
*** Java compilation tools ***
checking for javac... NONE
checking for javac... /usr/java/j2sdk1.4.2_07/bin/javac
checking wether the Java compiler (/usr/java/j2sdk1.4.2_07/bin/javac)
works... yes
checking for jar... NONE
checking for jar... /usr/java/j2sdk1.4.2_07/bin/jar
*** Host support ***
checking C flags dependant on host system type... ok
gcc flags added
*** Writing output files ***
configure: creating ./config.status
config.status: creating Makefile
config.status: creating Makedefs
config.status: creating native/Makefile
*** All done ***
Now you can issue "make"
[EMAIL PROTECTED] jsvc-src]# make
make -C native all
make[1]: Entering directory
`/tmp/jsvc/commons-daemon/bin/jsvc-src/native'
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c jsvc-unix.c -o jsvc-unix.o
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c arguments.c -o arguments.o
arguments.c: In function `arguments':
arguments.c:231: warning: unused variable `temp'
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c debug.c -o debug.o
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c dso-dlfcn.c -o dso-dlfcn.o
dso-dlfcn.c:51: warning: function declaration isn't a prototype
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c dso-dyld.c -o dso-dyld.o
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c help.c -o help.o
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c home.c -o home.o
gcc -g -O2 -DCPU=\"i386\" -DOS_LINUX -DDSO_DLFCN
-I/usr/java/j2re1.4.2/include -I/usr/java/j2re1.4.2/include/linux
-Wall -Wstrict-prototypes -c java.c -o java.o
java.c:22:17: jni.h: No such file or directory
java.c:35: parse error before '*' token
java.c:35: warning: type defaults to `int' in declaration of `jvm'
java.c:35: warning: data definition has no type or storage class
java.c:36: parse error before '*' token
java.c:36: warning: type defaults to `int' in declaration of `env'
java.c:36: warning: data definition has no type or storage class
java.c:37: parse error before "cls"
java.c:37: warning: type defaults to `int' in declaration of `cls'
java.c:37: warning: initialization makes integer from pointer without
a cast
java.c:37: warning: data definition has no type or storage class
java.c:42: parse error before '*' token
java.c:42: warning: function declaration isn't a prototype
java.c: In function `shutdown':
java.c:43: `reload' undeclared (first use in this function)
java.c:43: (Each undeclared identifier is reported only once
java.c:43: for each function it appears in.)
java.c: At top level:
java.c:49: warning: function declaration isn't a prototype
java.c: In function `java_init':
java.c:91: warning: implicit declaration of function `jint'
java.c:91: `symb' undeclared (first use in this function)
java.c:91: `JavaVM' undeclared (first use in this function)
java.c:91: parse error before ',' token
java.c:92: `JNINativeMethod' undeclared (first use in this function)
java.c:93: `JavaVMOption' undeclared (first use in this function)
java.c:93: `opt' undeclared (first use in this function)
java.c:95: `JavaVMInitArgs' undeclared (fi

Re: [Collections] Queue classes

[Stephen Colebourne]

Isn't this similar to the buffer interface?
Stephen
Is there any interest in adding some Queue classes to commons collections?
The following is what i have so far:
public interface Queue extends Collection {
Object remove();
Object get();
Object get(int index);
Object remove(int index);
int indexOf(Object object);}
}
public interface BoundedQueue extends Queue, BoundedCollection {
}
I have also provided the following implementation classes:
/*** A LIFO queue whose remove() method removes the most recently
  added item in the queue ***/
public class LifoQueue extends AbstractQueue { }
/*** A FIFO queue whose remove() method removes the least recently
  added item in the queue ***/
public class FifoQueue extends AbstractQueue { }
/*** Decorates a Queue to enforces "Set" semantics, so you cannot
have
  the same element in the queue twice (at the same time).  It
  can either use the .equals method, or a comparator for object
  comparison ***/
public class UniqueQueue implements Queue {
public UniqueQueue(Queue queue);
public UniqueQueue(Queue queue, Comparator comparator);
}
/*** Decorates a queue so that if you try to add an item to a Queue
  that has reached it's maximum size, it will remove an element
from
  the queue (uses the remove() method on the Queue interface, so
as
  to abide by the LIFO, FIFO, LRU semantics on the underlying
queue) ***/
public class RemovingBoundedQueue
extends AbstractBoundedQueue
implements BoundedQueue {
public RemovingBoundedQueue(int maxSize, Queue queue);
}
And the following utility class:
public class Queues {
 public static Queue synchronizedQueue(Queue queue);
 public static BoundedQueue
synchronizedBoundedQueue(BoundedQueue queue);
}
The BoundedQueue in and of itself is nice for history lists, where you 
want
to maintain
a certain amount of history, and throw anything beyond that away (which 
was
the purpose
of creating these classes anyway was to create a way for a text box to 
have
history,
by having changing it to a combo box, and hooking in the combo box model 
to
a Bounded
FIFO queue).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r157820 - jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/SetNextRule.java

[skitching]

Author: skitching
Date: Wed Mar 16 14:46:19 2005
New Revision: 157820

URL: http://svn.apache.org/viewcvs?view=rev&rev=157820
Log:
Minor javadoc update.

Modified:

jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/SetNextRule.java

Modified: 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/SetNextRule.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/SetNextRule.java?view=diff&r1=157819&r2=157820
==
--- 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/SetNextRule.java
 (original)
+++ 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/SetNextRule.java
 Wed Mar 16 14:46:19 2005
@@ -31,6 +31,14 @@
  * It is possible that this may break (some) code 
  * written against release 1.1.1 or earlier.
  * See [EMAIL PROTECTED] #isExactMatch()} for more details. 
+ *
+ * Note that while CallMethodRule uses commons-beanutils' data-conversion
+ * functionality (ConvertUtils class) to convert parameter values into
+ * the appropriate type for the parameter to the called method, this
+ * rule does not. Needing to use ConvertUtils functionality when building
+ * parent-child relationships is expected to be very rare; however if you 
+ * do need this then instead of using this rule, create a CallMethodRule
+ * specifying targetOffset of 1 in the constructor.
  */
 
 public class SetNextRule extends Rule {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34038] - Registered Converter not utilized when leveraging .addFactoryCreate

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34038


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 23:29 ---
Hi Ed,

Firstly, this is really a "how to use digester question", not a bug.
It would be better to post such a question to the
commons-user@jakarta.apache.org list than create a bugzilla entry (which is
meant to be for filing bugs and enhancement-requests).

I presume that what is happening is:
1)
You use FactoryCreateRule to create an instance of some object of class "X", and
this object is pushed onto the digester stack
2) 
You then use SetNextRule or CallMethodRule to pass the object on the top of the
stack (the one created above) to a method on the second-to-top object. The
method you want to be called has a parameter of type "Y", and you want your
custom converter to be used in order to convert from X to Y.

It doesn't matter that FactoryCreateRule's createObject method declares itself
to return Object; at runtime calling method obj.getClass() will return the
actual type, and this is what matters.

However the SetNextRule doesn't use ConvertUtils to convert parameter types;
only CallMethodRule provides this functionality. Digester 1.6 enhanced the
CallMethodRule class to take a "targetOffset" parameter to its constructor, so
CallMethodRule can now emulate SetNextRule (but with type conversion).

If you were not using SetNextRule, then I suggest you do some more investigation
(including turning digester logging on) then post your followup questions to the
commons-user email list. See http://wiki.apache.org/jakarta-commons/Digester/FAQ
for information on enabling logging in digester.

Regards,

Simon

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Collections] Queue classes

[Inger, Matthew]

Is there any interest in adding some Queue classes to commons collections?
The following is what i have so far:

public interface Queue extends Collection {
Object remove();
Object get();
Object get(int index);
Object remove(int index);
int indexOf(Object object);}
}

public interface BoundedQueue extends Queue, BoundedCollection {
}

I have also provided the following implementation classes:

/*** A LIFO queue whose remove() method removes the most recently
  added item in the queue ***/
public class LifoQueue extends AbstractQueue { }

/*** A FIFO queue whose remove() method removes the least recently
  added item in the queue ***/
public class FifoQueue extends AbstractQueue { }


/*** Decorates a Queue to enforces "Set" semantics, so you cannot
have
  the same element in the queue twice (at the same time).  It
  can either use the .equals method, or a comparator for object
  comparison ***/
public class UniqueQueue implements Queue {
public UniqueQueue(Queue queue);
public UniqueQueue(Queue queue, Comparator comparator);
}

/*** Decorates a queue so that if you try to add an item to a Queue
  that has reached it's maximum size, it will remove an element
from
  the queue (uses the remove() method on the Queue interface, so
as
  to abide by the LIFO, FIFO, LRU semantics on the underlying
queue) ***/
public class RemovingBoundedQueue
extends AbstractBoundedQueue
implements BoundedQueue {

public RemovingBoundedQueue(int maxSize, Queue queue);
}

And the following utility class:

public class Queues {
 public static Queue synchronizedQueue(Queue queue);
 public static BoundedQueue
synchronizedBoundedQueue(BoundedQueue queue);
}


The BoundedQueue in and of itself is nice for history lists, where you want
to maintain
a certain amount of history, and throw anything beyond that away (which was
the purpose
of creating these classes anyway was to create a way for a text box to have
history,
by having changing it to a combo box, and hooking in the combo box model to
a Bounded
FIFO queue). 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24056] - Documentation error in StringUtils.replace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=24056


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 22:05 ---
As per the online javadocs:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/StringUtils.html#replace(java.lang.String,%20java.lang.String,%20java.lang.String)

This seems to have not been fixed:

 StringUtils.replace(null, *, *)= null
 StringUtils.replace("", *, *)  = ""
 StringUtils.replace("aba", null, null) = "aba"
 StringUtils.replace("aba", null, null) = "aba"
 StringUtils.replace("aba", "a", null)  = "aba" 
 StringUtils.replace("aba", "a", "")= "aba" <-- here
 StringUtils.replace("aba", "a", "z")   = "zbz"

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Betwixt 0.6.1-dev] Unit test errors

[Marc DEXET]

Hi guys.
I don't undestand I get some unit test failures with last trunk betwixt 
that aren't showned in home project unit test reports.

Are they synchronized ?

My classpath meets project info requirements and tests are runned by maven.
Any idea ?



- list of (some) failures - 
org.apache.commons.betwixt.derived.TestWriteClass

Testcase:
testPropertySuppressionStrategy(org.apache.commons.betwixt.derived.TestWrite
Class): FAILED
Expected secrets to be supressed(Unequal node names) expected: but
was:
junit.framework.ComparisonFailure: Expected secrets to be supressed(Unequal
node names) expected: but was:


org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping

Testcase:
testBindTimeTypeWrite(org.apache.commons.betwixt.io.read.TestBindTimeTypeMap
ping):  FAILED
(Unequal node names) expected: but was:
junit.framework.ComparisonFailure: (Unequal node names) expected: but
was:

org.apache.commons.betwixt.io.read.TestMaps

- Standard Error -
16 mars 2005 19:03:00 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
16 mars 2005 19:03:00 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
-  ---
Testcase: testMapWithArray(org.apache.commons.betwixt.io.read.TestMaps):
FAILED
expected:<...ity>Chicago
1234
USA
12 here
  
  
Los Angeles
9
USA but was:<...ode>1234
USA
Chicago
12 here
  
  
9
USA
Los Angeles
junit.framework.ComparisonFailure: expected:<...ity>Chicago
1234
USA
12 here
  
  
Los Angeles
9
USA but was:<...ode>1234
USA
Chicago
12 here
  
  
9
USA
Los Angeles
at
org.apache.commons.betwixt.io.read.TestMaps.testMapWithArray(TestMaps.java:1
43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
-- 
Marc DeXeT
CNRS/DSI/BEST

DO NOT REPLY [Bug 34038] New: - Registered Converter not utilized when leveraging .addFactoryCreate

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34038

   Summary: Registered Converter not utilized when leveraging
.addFactoryCreate
   Product: Commons
   Version: 1.5 Final
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Digester
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I've created an object creation factory that extends
AbstractObjectCreationFactory, thus the createObject(org.xml.sax.Attributes
attributes) method returns an "Object".  I have also created a value converter
that implements Converter, that does some specific value handling, in the
convert(Class type, Object value) method.  The problem is that the "Class type"
object is not strongly typed, because it was created by the creation factory
that returns the generic "Object".  So, the registered value converter is never
used.

In the BeanUtils setProperty method, the type is known in the "bean" and
"target" variables, but the "type" is obviously java.lang.Object.

How can one utilize the value converters if one is creating objects using the
Factory Creation feature?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r157762 - in jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail: HtmlEmail.java MultiPartEmail.java

[proyal]

Author: proyal
Date: Wed Mar 16 07:19:36 2005
New Revision: 157762

URL: http://svn.apache.org/viewcvs?view=rev&rev=157762
Log:
Modify HTML message construction to always put the test/html before
any attachments

Modified:

jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/HtmlEmail.java

jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/MultiPartEmail.java

Modified: 
jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/HtmlEmail.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/HtmlEmail.java?view=diff&r1=157761&r2=157762
==
--- 
jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/HtmlEmail.java
 (original)
+++ 
jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/HtmlEmail.java
 Wed Mar 16 07:19:36 2005
@@ -291,12 +291,12 @@
 }
 
 // add sub containers to message
-this.addPart(subContainer);
+this.addPart(subContainer, 0);
 
if (this.inlineImages.size() > 0)
{
// add sub container to message
-   this.addPart(subContainerHTML);
+   this.addPart(subContainerHTML, 1);
}
 }
 
@@ -347,7 +347,7 @@
 else
 {
 msgHtml = new MimeBodyPart();
-container.addBodyPart(msgHtml);
+container.addBodyPart(msgHtml, 1);
 }
 }
 

Modified: 
jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/MultiPartEmail.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/MultiPartEmail.java?view=diff&r1=157761&r2=157762
==
--- 
jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/MultiPartEmail.java
 (original)
+++ 
jakarta/commons/proper/email/trunk/src/java/org/apache/commons/mail/MultiPartEmail.java
 Wed Mar 16 07:19:36 2005
@@ -115,14 +115,24 @@
  */
 public Email addPart(MimeMultipart multipart) throws EmailException
 {
+try{
+return addPart(multipart, getContainer().getCount());
+}
+catch( MessagingException me ){
+throw new EmailException(me);
+}
+}
+
+public Email addPart(MimeMultipart multipart, int index) throws 
EmailException
+{
 MimeBodyPart bodyPart = new MimeBodyPart();
 try {
 bodyPart.setContent(multipart);
-getContainer().addBodyPart(bodyPart);
+getContainer().addBodyPart(bodyPart, index);
 }
 catch (MessagingException me){
 throw new EmailException(me);
-}
+}
 
 return this;
 }
@@ -415,7 +425,7 @@
 if (this.primaryBodyPart == null)
 {
 primaryBodyPart = new MimeBodyPart();
-getContainer().addBodyPart(primaryBodyPart);
+getContainer().addBodyPart(primaryBodyPart, 0);
 }
 
 return primaryBodyPart;



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28291] - [logging] ContextClassLoader may load Log impl from wrong context in JDK 1.4

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28291





--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 13:21 ---
Robert, why would you think that putting commons-logging.jar in shared/lib would
resolve the issue? 

The problem is caused by Hashtable LogFactory.factories having an entry whose
key is a classloader that has been "undeployed". Shouldn't the solution be to
ensure that LogFactory gets loaded by the *component* classloader, not the
shared classloader, so that when the container "forgets" the component
classloader there are no longer any references to it (apart from circular ones
that the garbage collector can handle)? 

NB: we're talking about JCL-1.0.4 here (no weak references).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [beanutils] [logging]j2ee unit tests added: memory leak demonstrated (?)

[Simon Kitching]

On Wed, 2005-03-16 at 00:21 -0800, Brian Stansberry wrote:
> After exploring more with the JCL code, I'm almost
> certain the reference to FloatConverter in
> BeanUtilsBean.convertUtilsBean.converters is what's
> causing o.a.c.beanutils.converter.MemoryTestCase to
> fail.

I should have been a little clearer about MemoryTestCase.
There are two tests that are failing:

* testComponentRegistersCustomConverter
This fails for a reasonably obvious reason, and it's
the same one that is already documented in the javadoc
for JCL's WeakHashtable class. Unfortunately as this
test shows, it will be encountered quite often when
people use beanutils converter functionality in a
j2ee-like environment.

* testComponentRegistersStandardConverter
This fails for no reason I can understand. It is very similar
to testComponentRegistersCustomConverter except that it does
not involve loading a class via a child classloader, and
therefore should not trigger the bug I believe exists. 

And yes, commending out the reference to FloatConverter in the 
testComponentRegistersStandardConverter test does make it pass;
the million-dollar question is: why does the test fail when
FloatConverter is used? Maybe it's because when running 
"maven test", the unit test code is actually run within a
custom classloader? Does maven itself use BeanUtils? Hmm..

> 
> When I wrote before, I only said "likely" because I
> couldn't see why JCL wouldn't always have the same
> failure, and I had tests where it didn't.  But I've
> now created tests where it does (see below); tests
> that are basically analogous to MemoryTestCase.

Ok, I'm glad the same issue has been replicated in JCL;
I thought it would be. Well, glad may be the wrong word,
but at least I've not been proved a total idiot :-)

> Will have to be another day before I submit a patch
> for the JCL tests (after midnight now).  But, I've
> found in JCL the classloader is not released when
> LogFactoryImpl is loaded by a parent loader and the
> Log wrapper is loaded  by a child.  I've identified
> two basic configurations where this might happen:

Yep. Both of these (see below) cause exactly the scenario
you originally documented in the javadoc for class
WeakHashtable and that my javadoc patch expanded on 
(via Robert's editorial control :-).

It's just that the scenario is referred to as "unusual"
in the javadoc but I am now thinking it is reasonably common.

> 
> 1) Parent-first delegation model, where the parent has
> commons-logging-api.jar, child has commons-logging.jar
> and child wants to use Log4j or Avalon (or some custom
> Log implementation).

Yep. LogFactory is loaded by parent, but Log4jLogger is
loaded by child, because that class is not present in
the commons-logging-api.jar file.

So the WeakHashtable member of LogFactory contains an
entry keyed by the child classloader, with a value object
whose getClass().getClassLoader() points back to the
child classloader ==> the classloader never gets gc'd.

> 2) Child-first delegation model that uses the
> configuration I proposed in my "Further Analysis"
> document; i.e. where the parent has
> commons-logging-api-xxx.jar, child has
> commons-logging-impl.jar and child wants to use Log4j
> or Avalon.

Yep again.

LogFactory loaded by parent classloader because it 
isn't present in the commons-logging-impl.jar file.
Log4jLogger is loaded by child because it is.

And this leads back to the same scenario as above.



My conclusion is that writing the Singleton pattern
correctly in a j2ee environment is extremely difficult,
and may in fact be impossible. And unfortunately the
singleton pattern is in use in a number of commons
libs. 


I've been working on some weird ideas that *might* just
work, but I'm not ready to toss them out for review yet.


Note to others: this issue is quite separate from the
recent debate on commons-logging "discovery".

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed

[commons-jelly-tags-xml development]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-xml has an issue affecting its community integration.
This issue affects 12 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define :  Commons Jelly
- commons-jelly-tags-html :  Commons Jelly
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jaxme :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jface :  Commons Jelly
- commons-jelly-tags-jsl :  Commons Jelly
- commons-jelly-tags-swing :  Commons Jelly
- commons-jelly-tags-xml :  Commons Jelly
- commons-jelly-tags-xmlunit :  Commons Jelly
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools


Full details are available at:

http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-xml-16032005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html
Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-16032005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-16032005.jar
-
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:compile:
[echo] Compiling to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes
[echo] 
==

  NOTE: Targetting JVM 1.4, classes
  will not run on earlier JVMs

==
  
[javac] Compiling 16 source files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:jar-resources:

test:prepare-filesystem:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports

test:test-resources:
Copying 36 files to 
/home/gump/workspaces2/public/workspace/commons-je

Re: [beanutils] [logging]j2ee unit tests added: memory leak demonstrated (?)

[Brian Stansberry]

Replying to myself:
--- Brian Stansberry <[EMAIL PROTECTED]>
wrote:
> Simon,
> 
> I spent some time last night looking at this, mostly
> just familiarizing myself with how beanutils works
> so
> I could understand the problem.
> 
> I think you're right to be concerned about JCL, as
> from what I can see the two applications are very
> similar:
> 
> "weak-keyed" map (aka "WeakMap") held statically by
> class loaded by container (beanutils:
> BeanUtilsBean.beanByClassLoader; JCL:
> LogFactory.factories).
> 
> WeakMap key is the TCCL.
> 
> WeakMap value is a class loaded by container, but
> value is instantiated while component loader is the
> TCCL (beanutils: BeanUtilsBean; JCL:
> LogFactoryImpl).
> 
> WeakMap value holds another map (aka "StrongMap")
> (beanutils:
> BeanUtilsBean.convertUtilsBean.converters;
> JCL: LogFactory.instances)
> 
> StrongMap value is a class loaded by the component
> loader (beanutils: FloatConverter; JCL:
> Log4jLogger). 
> Class implements an interface loaded by the
> container
> loader (beanutils: Converter; JCL: Log).  This
> reference is likely what's preventing release of the
> classloader in beanutils.
> 

After exploring more with the JCL code, I'm almost
certain the reference to FloatConverter in
BeanUtilsBean.convertUtilsBean.converters is what's
causing o.a.c.beanutils.converter.MemoryTestCase to
fail.

When I wrote before, I only said "likely" because I
couldn't see why JCL wouldn't always have the same
failure, and I had tests where it didn't.  But I've
now created tests where it does (see below); tests
that are basically analogous to MemoryTestCase.

> I noticed that the JCL unit test I wrote for memory
> release has a weakness in that it doesn't add the
> Log
> instance to LogFactoryImpl.instances.  I noticed
> that
> a week ago and added the required call so I could
> check the tests still passed.  They did.  But,
> didn't
> get a chance to clean up the code and submit a
> proper
> patch for the tests.  My bad :(
> 
> I'll for sure do that tonight, plus add some more
> assertions like the beanutils test has in order to
> ensure that classes are being loaded by the intended
> loader.  This should either surface a problem in JCL
> or help shed some light on the beanutils problem.
> 

Will have to be another day before I submit a patch
for the JCL tests (after midnight now).  But, I've
found in JCL the classloader is not released when
LogFactoryImpl is loaded by a parent loader and the
Log wrapper is loaded  by a child.  I've identified
two basic configurations where this might happen:

1) Parent-first delegation model, where the parent has
commons-logging-api.jar, child has commons-logging.jar
and child wants to use Log4j or Avalon (or some custom
Log implementation).

2) Child-first delegation model that uses the
configuration I proposed in my "Further Analysis"
document; i.e. where the parent has
commons-logging-api-xxx.jar, child has
commons-logging-impl.jar and child wants to use Log4j
or Avalon.


Brian



__ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]