Re: [logging] detecting logging libs

[Brian Stansberry]

--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-05-22 at 20:56 -0700, Brian Stansberry
> wrote:
> > --- Simon Kitching <[EMAIL PROTECTED]> wrote:
> 
> > > I'd be happy with including this approach in the
> > > next release, removing
> > > the redundant isXYZAvailable methods and calling
> the
> > > next release 1.1.
> > > In practice, I'm sure no-one *does* subclass
> > > LogFactoryImpl so there's
> > > no problem.  In fact I'd be happier with this
> than a
> > > 1.0.5 where the
> > > methods exist but don't do anything.
> > >
> > 
> > +1
> 
> Ok. So questions:
>  * Robert are you ok with adopting Brian's approach
> to
>checking a logger is ok (by creating one) rather
> than
>using the current isXYZAvailable?
>  * Robert, are you ok with ripping out the
> isXYZAvailable
>methods and calling the next release 1.1?
>  * Brian: if Robert's ok with this (and no-one else
>votes -1), will you prepare an actual patch or
> should I?
> 

I'd be happy to.

> By the way, Brian, are you an Apache committer?
>

No.
 
> Regards,
> 
> Simon
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



__ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

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

Re: [RESULT][VOTE][VFS] Promote commons-vfs to commons proper

[Mario Ivankovits]

Martin Cooper wrote:

It would be nice if someone could check if my (imario) svn access rights
for commons-proper are correctly setup and if needed adjust them.
And if one could add VFS to the bugzilla components list I would be
thankful too.
   


Both done.
 

Thanks!

---
Mario


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

Re: [logging] detecting logging libs

[Simon Kitching]

On Sun, 2005-05-22 at 20:56 -0700, Brian Stansberry wrote:
> --- Simon Kitching <[EMAIL PROTECTED]> wrote:

> > I'd be happy with including this approach in the
> > next release, removing
> > the redundant isXYZAvailable methods and calling the
> > next release 1.1.
> > In practice, I'm sure no-one *does* subclass
> > LogFactoryImpl so there's
> > no problem.  In fact I'd be happier with this than a
> > 1.0.5 where the
> > methods exist but don't do anything.
> >
> 
> +1

Ok. So questions:
 * Robert are you ok with adopting Brian's approach to
   checking a logger is ok (by creating one) rather than
   using the current isXYZAvailable?
 * Robert, are you ok with ripping out the isXYZAvailable
   methods and calling the next release 1.1?
 * Brian: if Robert's ok with this (and no-one else
   votes -1), will you prepare an actual patch or should I?

By the way, Brian, are you an Apache committer?

Regards,

Simon


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

DO NOT REPLY [Bug 34766] - [digester] CallMethodRule doesn't call with null parameters, String-ifies them first.

[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=34766


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 06:13 ---
Javadoc updated, so I'm closing this entry.

-- 
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: r177915 - /jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/CallMethodRule.java

[skitching]

Author: skitching
Date: Sun May 22 21:12:35 2005
New Revision: 177915

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

Modified:

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

Modified: 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/CallMethodRule.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/CallMethodRule.java?rev=177915&r1=177914&r2=177915&view=diff
==
--- 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/CallMethodRule.java
 (original)
+++ 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/CallMethodRule.java
 Sun May 22 21:12:35 2005
@@ -66,7 +66,8 @@
  * there is no parameter info available from the XML. However parameters of
  * type Float and Integer will be passed a real object containing a zero value
  * as that is the output of the default ConvertUtils converters for those
- * types when passed a null. See the beautils documentation for more info.
+ * types when passed a null. You can register custom converters to change
+ * this behaviour; see the beautils library documentation for more info.
  *
  * Note that when a constructor is used with paramCount=0, indicating that
  * the body of the element is to be passed to the target method, an empty 



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

Re: [logging] detecting logging libs

[Brian Stansberry]

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

> On Sun, 2005-05-22 at 18:38 -0700, Brian Stansberry
> wrote:
> > It's a good point; the "assumed" category names in
> the
> > various isXYZAvailable method is my biggest
> dislike
> > about the patch I submitted.  Actually, if an
> approach
> > like the patch were adopted, I think we should
> > consider marking those methods as deprecated
> (they're
> > not used in the patched LogFactoryImpl itself) and
> > dropping them at the next release with a point
> scope
> > that allows it.
> 
> Ah - I see. With your approach, you just pass the
> name that the user
> provided, so don't need a dummy category name at
> all. Fine.
> 
> Regarding deprecation, if we're going to change the
> logic flow within
> the LogFactoryImpl such that the existing
> isXYZAvailable methods are no
> longer called, then to me that's *just as much* an
> incompatible change
> as removing the methods. 
> 
> Removing the methods potentially causes subclasses
> to not compile/link,
> but leaving them there and not calling them causes
> subclasses to
> *logically* fail, which in my view is even worse
> because it's not
> visible.
> 

+1

I'd tended to think about this in terms of a subclass
writing its own logic flow but calling into the
various isXYZAvailable methods, but you're right, a
subclass could also count on the superclass logic flow
but override an isXYZAvailable.  This is more likely
even.

> I'd be happy with including this approach in the
> next release, removing
> the redundant isXYZAvailable methods and calling the
> next release 1.1.
> In practice, I'm sure no-one *does* subclass
> LogFactoryImpl so there's
> no problem.  In fact I'd be happier with this than a
> 1.0.5 where the
> methods exist but don't do anything.
>

+1

A major refactor of the core class in the library
seems a bit much for two-decima point release name.
 
> > 
> > In general, if any significant work on
> LogFactoryImpl
> > is done I think a review of its API would be good.
> 
> > This seems to me to be the kind of class that if
> > someone wants a different implementation, they
> should
> > write a different implementation and not count on
> a
> > lot  of behaviors exposed by a superclass.
> 
> I'm working on a major refactoring proposal now,
> that will not just
> review but gut LogFactoryImpl :-).
> 
> > 
> > Looking into it more, I remembered that
> > LogFactoryImpl.getInstance(Class clazz) just calls
> > getInstance(clazz.getName()) and thus already
> creates
> > a requirement that Log implementations support
> fully
> > qualified class names.  So any adapter that
> doesn't do
> > this must be designed to work with a custom
> > LogFactory.  So, the potential list of users
> affected
> > by this issue is smaller -- only those with custom
> > LogFactory implementations and Log implementations
> > that don't support class names.
> 
> Yes, good point. We should really document that in
> the Log interface. In
> order to be able to swap in/out alternative logging
> implementations,
> there does need to be a "standard" for category
> names that the concrete
> Log classes can all handle. It's implicit in the
> whole concept of JCL
> (well, any logging wrapper).
> 
> 
> > Half-baked idea to throw out before I run.  Add to
> > LogFactoryImpl:
> > 
> > /**
> >  * Returns a category that can be used to test
> whether
> >  * an instance of a Log can be
> created.
> >  * 
> >  * This default implementation returns the fully 
> >  * qualified name of this class.  Subclasses
> should
> >  * override this if they support Log
> >  * implementations that cannot handle this
> category.
> >  * 
> >  */
> > protected String getTestCategory() {
> >   return getClass().getName();
> > }
> > 
> > All the various isXYZAvailable methods would call
> this
> > method when creating a test instance.
> 
> No need I think. Your code in bugzilla which simply
> uses the first log
> category passed in by the user seems fine to me.
> 

Good.  The above would only be relevant if the unused
isXYZAvailable methods were left in, and you make a
good argument for removing them.

> One minor issue: if the user passes in an "invalid"
> category name of
> some sort, then we might assume that the logging
> implementation is not
> available. Not a likely problem though.
> 
> And as you point out above, JCL effectively imposes
> its own standard on
> what is and is not a valid category name anyway, so
> if the above is
> really considered a problem then we can just declare
> that "" is always a
> valid category name that returns the "root"
> category, and all Log
> subclasses need to handle that category name.
> 
> 
> Hmm.. what about when a logging implementation is
> available, but
> attempting to create a logger fails, eg because the
> underlying
> implementation's config file is bad. If we test for
> the existence of the
> logging lib by creating a logger, then we would fall
> back to other
> logging libs in this case - is that what we want?
>

I th

Re: [math] setSubMatrix patch

[Phil Steitz]

No need to apologize.  Your contributions are most appreciated.  Let
me know if you need help getting set up or anything.  Thanks!

Phil

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

DO NOT REPLY [Bug 35007] - [math] setSubMatrix method

[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=35007





--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 05:39 ---
Created an attachment (id=15127)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15127&action=view)
unit test for setSubMatrix in RealMatrix

unit test for complete and partial replacement from subMatrix and invalid index
exception

-- 
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 35007] - [math] setSubMatrix method

[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=35007





--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 05:36 ---
Created an attachment (id=15126)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15126&action=view)
setSubMatrix method added.

This method use System.arrayCopy to perform set subMatrix.


-- 
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 33347] - [logging] Allow logging additional fields to database

[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=33347


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 04:21 ---
No existing logging library I am aware of takes parameters for specific pieces
of data such as userid; logging libraries (java.util.logging, log4j, avalon)
just deal in string messages and priorities.

And as commons-logging is intended to be a simple lowest-common-denominator
wrapper over other logging libraries, commons-logging is not the appropriate
place for such features.

I think this problem is best addressed separately from "logging" in the sense
that all the above mentioned libraries use the term.

-- 
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: [logging] detecting logging libs

[Simon Kitching]

On Sun, 2005-05-22 at 18:38 -0700, Brian Stansberry wrote:
> It's a good point; the "assumed" category names in the
> various isXYZAvailable method is my biggest dislike
> about the patch I submitted.  Actually, if an approach
> like the patch were adopted, I think we should
> consider marking those methods as deprecated (they're
> not used in the patched LogFactoryImpl itself) and
> dropping them at the next release with a point scope
> that allows it.

Ah - I see. With your approach, you just pass the name that the user
provided, so don't need a dummy category name at all. Fine.

Regarding deprecation, if we're going to change the logic flow within
the LogFactoryImpl such that the existing isXYZAvailable methods are no
longer called, then to me that's *just as much* an incompatible change
as removing the methods. 

Removing the methods potentially causes subclasses to not compile/link,
but leaving them there and not calling them causes subclasses to
*logically* fail, which in my view is even worse because it's not
visible.

I'd be happy with including this approach in the next release, removing
the redundant isXYZAvailable methods and calling the next release 1.1.
In practice, I'm sure no-one *does* subclass LogFactoryImpl so there's
no problem.  In fact I'd be happier with this than a 1.0.5 where the
methods exist but don't do anything.

> 
> In general, if any significant work on LogFactoryImpl
> is done I think a review of its API would be good. 
> This seems to me to be the kind of class that if
> someone wants a different implementation, they should
> write a different implementation and not count on a
> lot  of behaviors exposed by a superclass.

I'm working on a major refactoring proposal now, that will not just
review but gut LogFactoryImpl :-).

> 
> Looking into it more, I remembered that
> LogFactoryImpl.getInstance(Class clazz) just calls
> getInstance(clazz.getName()) and thus already creates
> a requirement that Log implementations support fully
> qualified class names.  So any adapter that doesn't do
> this must be designed to work with a custom
> LogFactory.  So, the potential list of users affected
> by this issue is smaller -- only those with custom
> LogFactory implementations and Log implementations
> that don't support class names.

Yes, good point. We should really document that in the Log interface. In
order to be able to swap in/out alternative logging implementations,
there does need to be a "standard" for category names that the concrete
Log classes can all handle. It's implicit in the whole concept of JCL
(well, any logging wrapper).


> Half-baked idea to throw out before I run.  Add to
> LogFactoryImpl:
> 
> /**
>  * Returns a category that can be used to test whether
>  * an instance of a Log can be created.
>  * 
>  * This default implementation returns the fully 
>  * qualified name of this class.  Subclasses should
>  * override this if they support Log
>  * implementations that cannot handle this category.
>  * 
>  */
> protected String getTestCategory() {
>   return getClass().getName();
> }
> 
> All the various isXYZAvailable methods would call this
> method when creating a test instance.

No need I think. Your code in bugzilla which simply uses the first log
category passed in by the user seems fine to me.

One minor issue: if the user passes in an "invalid" category name of
some sort, then we might assume that the logging implementation is not
available. Not a likely problem though.

And as you point out above, JCL effectively imposes its own standard on
what is and is not a valid category name anyway, so if the above is
really considered a problem then we can just declare that "" is always a
valid category name that returns the "root" category, and all Log
subclasses need to handle that category name.


Hmm.. what about when a logging implementation is available, but
attempting to create a logger fails, eg because the underlying
implementation's config file is bad. If we test for the existence of the
logging lib by creating a logger, then we would fall back to other
logging libs in this case - is that what we want?


Regards,

Simon



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

DO NOT REPLY [Bug 34792] - [logging] setUpHandlers leaves handlers null pointer

[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=34792





--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 03:43 ---
Created an attachment (id=15120)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15120&action=view)
patch to jdk14 test case to handle incorrect handler setup

Here's an alternative solution to your problem (I hope). I've committed this
patch as subversion revision 177867. If you have any issues with this, please
let me know. Otherwise I will close this bug report in about a week's time.

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]

svn commit: r177867 - /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigTestCase.java

[skitching]

Author: skitching
Date: Sun May 22 18:41:23 2005
New Revision: 177867

URL: http://svn.apache.org/viewcvs?rev=177867&view=rev
Log:
Add better reporting when jdk14 handler setup isn't right.

Modified:

jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigTestCase.java

Modified: 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigTestCase.java?rev=177867&r1=177866&r2=177867&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigTestCase.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigTestCase.java
 Sun May 22 18:41:23 2005
@@ -276,10 +276,24 @@
 parent = parent.getParent();
 }
 handlers = parent.getHandlers();
-if ((handlers != null) && (handlers.length == 1) &&
-(handlers[0] instanceof TestHandler)) {
-handler = (TestHandler) handlers[0];
-}
+
+// The CustomConfig.properties file explicitly defines one handler 
class
+// to be attached to the root logger, so if it isn't there then 
+// something is badly wrong...
+//
+// Yes this testing is also done in testPristineHandlers but
+// unfortunately:
+//  * we need to set up the handlers variable here, 
+//  * we don't want that to be set up incorrectly, as that can
+//produce weird error messages in other tests, and
+//  * we can't rely on testPristineHandlers being the first
+//test to run.
+// so we need to test things here too.
+assertNotNull("No Handlers defined for JDK14 logging", handlers);
+assertEquals("Unexpected number of handlers for JDK14 logging", 1, 
handlers.length);
+assertNotNull("Handler is null", handlers[0]);
+assertTrue("Handler not of expected type", handlers[0] instanceof 
TestHandler);
+handler = (TestHandler) handlers[0];
 }
 
 



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

Re: [logging] detecting logging libs

[Brian Stansberry]

--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-05-22 at 21:01 +0100, robert burrell
> donkin wrote:
> > On Sun, 2005-05-22 at 10:43 +,
> [EMAIL PROTECTED] wrote:
> > 
> > 
> > 
> > >  protected boolean
> isJdk13LumberjackAvailable() {
> > >  
> > > +// note: the algorithm here is
> different from isLog4JAvailable.
> > > +// I think isLog4JAvailable is
> correctsee bugzilla#31597
> > 
> > +1
> > 
> > could do with going through all the isAvailable's
> and checking whether
> > their algorithms are correct. however, i suspect
> that brian's approach
> > will be needed to deal correctly with some
> circumstances. if no one
> > feels like volunteering should probably record
> this in bugzilla so we
> > don't lose track...
> 
> If by "brian's approach" you mean creating an
> instance of the logger
> class in order to test whether that logging lib is
> *really* available, I
> agree. 
> 
> Not only is it more reliable, but it's a cleaner
> solution; currently the
> LogFactoryImpl class is making *assumptions* about
> what classes the
> various logging adapters depend on. That information
> should be only in
> the logging adapter class.
> 
> The only problem with creating an instance of the
> logger is that we
> would have to pass a category string to the logger
> constructor, and
> therefore must build an assumption into
> LogFactoryImpl about what
> category names are valid for the underlying logger.
> Can we assume that
> an empty string is a valid category for all logger
> libraries? Can we
> assume that "apache" or "org.apache.commons.logging"
> are valid category
> strings? Perhaps some loggers only accept valid URLs
> as
> categories...yes, I'm playing devil's advocate a bit
> here. 

It's a good point; the "assumed" category names in the
various isXYZAvailable method is my biggest dislike
about the patch I submitted.  Actually, if an approach
like the patch were adopted, I think we should
consider marking those methods as deprecated (they're
not used in the patched LogFactoryImpl itself) and
dropping them at the next release with a point scope
that allows it.

In general, if any significant work on LogFactoryImpl
is done I think a review of its API would be good. 
This seems to me to be the kind of class that if
someone wants a different implementation, they should
write a different implementation and not count on a
lot  of behaviors exposed by a superclass.

Of course, any kind of deprecation doesn't solve the
immediate problem.

Looking into it more, I remembered that
LogFactoryImpl.getInstance(Class clazz) just calls
getInstance(clazz.getName()) and thus already creates
a requirement that Log implementations support fully
qualified class names.  So any adapter that doesn't do
this must be designed to work with a custom
LogFactory.  So, the potential list of users affected
by this issue is smaller -- only those with custom
LogFactory implementations and Log implementations
that don't support class names.

> I guess we
> could always say that the writer of the logging
> adapter is required to
> return a valid logger instance for category "", even
> if that is not
> normally a category that is valid to the underlying
> library.
> 

Half-baked idea to throw out before I run.  Add to
LogFactoryImpl:

/**
 * Returns a category that can be used to test whether
 * an instance of a Log can be created.
 * 
 * This default implementation returns the fully 
 * qualified name of this class.  Subclasses should
 * override this if they support Log
 * implementations that cannot handle this category.
 * 
 */
protected String getTestCategory() {
  return getClass().getName();
}

All the various isXYZAvailable methods would call this
method when creating a test instance.

Brian

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




__ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

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

svn commit: r177071 - in /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging: LogFactory.java impl/LogFactoryImpl.java impl/SimpleLog.java

[skitching]

Author: skitching
Date: Sun May 22 18:04:54 2005
New Revision: 177071

URL: http://svn.apache.org/viewcvs?rev=177071&view=rev
Log:
Fix javadoc and fix java1.5 compile warnings.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?rev=177071&r1=177070&r2=177071&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 Sun May 22 18:04:54 2005
@@ -729,11 +729,13 @@
 
 try {
 // Are we running on a JDK 1.2 or later system?
-Method method = Thread.class.getMethod("getContextClassLoader", 
null);
+Method method = Thread.class.getMethod("getContextClassLoader", 
+(Class[]) null);
 
 // Get the thread context class loader (if there is one)
 try {
-classLoader = 
(ClassLoader)method.invoke(Thread.currentThread(), null);
+classLoader = 
(ClassLoader)method.invoke(Thread.currentThread(), 
+(Object[]) null);
 } catch (IllegalAccessException e) {
 throw new LogConfigurationException
 ("Unexpected IllegalAccessException", e);
@@ -915,7 +917,7 @@
  * @param factoryClass
  * @param classLoader
  * 
- * @returns either a LogFactory object or a LogConfigurationException 
object.
+ * @return either a LogFactory object or a LogConfigurationException 
object.
  */
 protected static Object createFactory(String factoryClass, ClassLoader 
classLoader) {
 
@@ -1215,7 +1217,7 @@
  * the specified object's class has overidden the toString method.
  * 
  * @param o may be null.
- * @return
+ * @return a string of form [EMAIL PROTECTED], or "null" if param o is 
null.
  */
 public static String objectId(Object o) {
 if (o == null) {

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java?rev=177071&r1=177070&r2=177071&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
 Sun May 22 18:04:54 2005
@@ -660,7 +660,7 @@
 loadClass("java.util.logging.Logger");
 loadClass("org.apache.commons.logging.impl.Jdk14Logger");
 Class throwable = loadClass("java.lang.Throwable");
-if (throwable.getDeclaredMethod("getStackTrace", null) == null) {
+if (throwable.getDeclaredMethod("getStackTrace", (Class[]) null) 
== null) {
 return (false);
 }
 logDiagnostic("Found Jdk14.");

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java?rev=177071&r1=177070&r2=177071&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
 Sun May 22 18:04:54 2005
@@ -586,11 +586,13 @@
 if (classLoader == null) {
 try {
 // Are we running on a JDK 1.2 or later system?
-Method method = 
Thread.class.getMethod("getContextClassLoader", null);
+Method method = Thread.class.getMethod("getContextClassLoader",
+(Class[]) null);
 
 // Get the thread context class loader (if there is one)
 try {
-classLoader = 
(ClassLoader)method.invoke(Thread.currentThread(), null);
+classLoader = 
(ClassLoader)method.invoke(Thread.currentThread(), 
+(Class[]) null);
 } catch (IllegalAccessException e) {
 ;  // ignore
 } catch (InvocationTargetException e) {



---

svn commit: r176581 - /jakarta/commons/proper/logging/trunk/project.properties

[skitching]

Author: skitching
Date: Sun May 22 18:02:02 2005
New Revision: 176581

URL: http://svn.apache.org/viewcvs?rev=176581&view=rev
Log:
Ensure class file format is compatible with JVM 1.1

Modified:
jakarta/commons/proper/logging/trunk/project.properties

Modified: jakarta/commons/proper/logging/trunk/project.properties
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/project.properties?rev=176581&r1=176580&r2=176581&view=diff
==
--- jakarta/commons/proper/logging/trunk/project.properties (original)
+++ jakarta/commons/proper/logging/trunk/project.properties Sun May 22 18:02:02 
2005
@@ -24,4 +24,6 @@
 
 maven.junit.fork=true
 
-logging.cvs=pserver:[EMAIL PROTECTED]:/home/cvspublic
+# generate .class files that can be loaded into a version 1.1 JVM.
+maven.compile.target=1.1
+maven.compile.source=1.2
\ No newline at end of file



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

svn commit: r176497 - /jakarta/commons/proper/logging/trunk/maven.xml

[skitching]

Author: skitching
Date: Sun May 22 18:01:36 2005
New Revision: 176497

URL: http://svn.apache.org/viewcvs?rev=176497&view=rev
Log:
Updated obsolete goal java:jar to jar:jar
Removed obsolete exclude of CVS subdirs

Modified:
jakarta/commons/proper/logging/trunk/maven.xml

Modified: jakarta/commons/proper/logging/trunk/maven.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/maven.xml?rev=176497&r1=176496&r2=176497&view=diff
==
--- jakarta/commons/proper/logging/trunk/maven.xml (original)
+++ jakarta/commons/proper/logging/trunk/maven.xml Sun May 22 18:01:36 2005
@@ -16,7 +16,7 @@
 
 -->
 
-
 
   
@@ -28,7 +28,6 @@
 
   

-   
   
 
   



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

Re: [logging] Improvements to LogFactoryImpl

[Simon Kitching]

On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry wrote:
> >
> >i believe (as indicated in the analysis document)
> that the correct
> >behaviour in these cases is for JCL to recognise that
> log4j is not
> >viable (for this configuration) and default to
> java.util logging. this
> >is a little unsatisfactory but i don't see a
> reasonable technical
> >solution for these configuration.
> >
> 
> One unsatisfactory aspect is that instead of throwing
> an exception with a nice message and stack trace,
> logging would mysteriously be done using an unexpected
> logging library.  But Simon's recent work on adding
> diagnostics should help mitigate this drawback.

I presume you're continuing the discussion:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=34661

The bit about trying to instantiate a logger object in order to test
whether that library is *really* available has my +1.

The bit about ignoring the situation where we can't cast the resulting
object to Log (and continuing with discovery) is something I've been
trying to make up my mind on.

When the user *has* put an implementation of the Log interface into the
child classloader, so that this problem occurs, we can:
a) report an error, or
b) use a logging lib that the parent can access

When the user doesn't actually have any interest in log output, (b) is
obviously superior. It's a shame that at the moment we prevent apps from
running even when no logging would ever be generated. Falling back to
another implementation (even SimpleLog or NoOpLog) is fine when no
output is generated or the user doesn't want the output!

And sometimes the user is happy with (b) anyway, ie they feel it's ok
that logging from code in the child goes to one destination while
logging from code in the parent (even when directly invoked by the
child) goes elsewhere.

But sometimes users will *really* expect all their logging to go to one
place regardless of whether the code is deployed in the child or parent.
And in this situation, silently "splitting" the output will really
confuse them.

In the past, I've had a slight lean towards (a), ie the current
solution. If the system *might* do unexpected things it seems safer to
report the error than not. 

But now diagnostics are available, I could be persuaded towards
implementing the proposed patch. The situation where the app terminates
in the middle because child code called parent code that uses logging is
nasty. And with diagnostics, a user who wonders "why didn't my logging
output go where I expected it?" can find out.


Regards,

Simon


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

DO NOT REPLY [Bug 32691] - [logging] Convenience methods for cleaner application code

[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=32691


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




-- 
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 34188] - [logging] Proposal: Support for Ugli as published in Log4j 1.3alpha

[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=34188


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




-- 
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: r173035 - /jakarta/commons/proper/commons-build/trunk/xdocs/svninfo.xml

[skitching]

Author: skitching
Date: Sun May 22 17:00:45 2005
New Revision: 173035

URL: http://svn.apache.org/viewcvs?rev=173035&view=rev
Log:
Add info on problem selecting by date in subversion.

Modified:
jakarta/commons/proper/commons-build/trunk/xdocs/svninfo.xml

Modified: jakarta/commons/proper/commons-build/trunk/xdocs/svninfo.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/xdocs/svninfo.xml?rev=173035&r1=173034&r2=173035&view=diff
==
--- jakarta/commons/proper/commons-build/trunk/xdocs/svninfo.xml (original)
+++ jakarta/commons/proper/commons-build/trunk/xdocs/svninfo.xml Sun May 22 
17:00:45 2005
@@ -113,7 +113,18 @@
 If you want the latest code, you generally want the directory 
{component-name}/trunk,
 though you should check the project directory structure first via one of the 
methods
 listed above, as different projects may use different internal directory 
structures.
-
+
+Important! At the current time, selecting by date in subversion within 
the
+ASF repository isn't reliable. The reason is that when converting a date to a 
revision
+number, subversion assumes that revision N has an earlier date than revision 
N+M, and
+that it can therefore perform a binary search on revision numbers to locate 
one with
+the required date. However CVS imports of data that retain the original date
+information from CVS break this assumption. And unfortunately because revisions
+are repository-wide information, this affects date-based searches
+even in directories unrelated to the ones that CVS stuff was imported into.
+So while dates are reported correctly in "svn log" output, only revision 
numbers should
+be used with the -r option. See issue #752 in the subversion issue tracker at 
tigris.org.
+
 
 For more information on connecting to the ASF Subversion repository, see the 
 Subversion section of the



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

svn commit: r172281 - /jakarta/commons/proper/commons-build/trunk/menus/community.ent

[skitching]

Author: skitching
Date: Sun May 22 16:53:40 2005
New Revision: 172281

URL: http://svn.apache.org/viewcvs?rev=172281&view=rev
Log:
Remove link to jakarta repository info in jakarta community navbar section.
This information is too generic for commons users; the links available from
the commons site are more useful/targetted.

Modified:
jakarta/commons/proper/commons-build/trunk/menus/community.ent

Modified: jakarta/commons/proper/commons-build/trunk/menus/community.ent
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/menus/community.ent?rev=172281&r1=172280&r2=172281&view=diff
==
--- jakarta/commons/proper/commons-build/trunk/menus/community.ent (original)
+++ jakarta/commons/proper/commons-build/trunk/menus/community.ent Sun May 22 
16:53:40 2005
@@ -4,5 +4,4 @@
 
 http://jakarta.apache.org/site/getinvolved.html"/>
 http://jakarta.apache.org/site/mail.html"/>
-http://jakarta.apache.org/site/cvsindex.html"/>
 



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

svn commit: r171995 - /jakarta/commons/proper/commons-build/trunk/menus/view.ent

[skitching]

Author: skitching
Date: Sun May 22 16:52:14 2005
New Revision: 171995

URL: http://svn.apache.org/viewcvs?rev=171995&view=rev
Log:
Enhance source code repo links in commons site navbar.

Modified:
jakarta/commons/proper/commons-build/trunk/menus/view.ent

Modified: jakarta/commons/proper/commons-build/trunk/menus/view.ent
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/menus/view.ent?rev=171995&r1=171994&r2=171995&view=diff
==
--- jakarta/commons/proper/commons-build/trunk/menus/view.ent (original)
+++ jakarta/commons/proper/commons-build/trunk/menus/view.ent Sun May 22 
16:52:14 2005
@@ -1,7 +1,10 @@
 
- 
-http://svn.apache.org/viewcvs/jakarta/commons/proper/"/>
-http://svn.apache.org/viewcvs/jakarta/commons/sandbox/"/>
+  
+http://jakarta.apache.org/commons/svninfo.html"/>
+http://svn.apache.org/viewcvs/jakarta/commons/proper/"/>
+http://svn.apache.org/repos/asf/jakarta/commons/proper/"/>
+http://svn.apache.org/viewcvs/jakarta/commons/sandbox/"/>
+http://svn.apache.org/repos/asf/jakarta/commons/sandbox/"/>
 



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

svn commit: r171385 - /jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml

[skitching]

Author: skitching
Date: Sun May 22 16:48:13 2005
New Revision: 171385

URL: http://svn.apache.org/viewcvs?rev=171385&view=rev
Log:
Clarified cause of subversion date problems.

Modified:
jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml

Modified: jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml?rev=171385&r1=171384&r2=171385&view=diff
==
--- jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml 
(original)
+++ jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml Sun 
May 22 16:48:13 2005
@@ -166,12 +166,15 @@
 

IMPORTANT! At the current time, selecting by date in subversion 
within the
-   ASF repository isn't reliable. The reason is that imports of data from 
CVS
-   repositories into any part of the subversion repository stuffs 
up subversion's
-   date-based indexes for all modifications prior to that import, even in 
non-related
-   parts of the repository (the indexes are repository-wide). So while 
dates are
-   reported correctly in "svn log" output, only revision numbers should be 
used with
-   the -r option. See issue #752 in the subversion issue tracker at 
tigris.org.
+   ASF repository isn't reliable. The reason is that when converting a 
date to a revision
+   number, subversion assumes that revision N has an earlier date than 
revision N+M, and
+   that it can therefore perform a binary search on revision numbers to 
locate one with
+   the required date. However CVS imports of data that retain the original 
date
+   information from CVS break this assumption. And unfortunately because 
revisions
+   are repository-wide information, this affects date-based searches
+   even in directories unrelated to the ones that CVS stuff was imported 
into.
+   So while dates are reported correctly in "svn log" output, only 
revision numbers should
+   be used with the -r option. See issue #752 in the subversion issue 
tracker at tigris.org.

 
 



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

DO NOT REPLY [Bug 32619] - [lang] Minor tweak to fix of bug # 26616

[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=32619


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




-- 
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 26876] - [lang] Enum.equals does not handle different class loaders.

[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=26876


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 01:29 ---
*** Bug 34600 has been marked as a duplicate of this bug. ***

-- 
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 34600] - [lang] Enum.equals() is too fragile

[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=34600


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 01:29 ---
Fixed already

*** This bug has been marked as a duplicate of 26876 ***

-- 
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: [jelly] SOLVED: Maven issue with Hans memory leak patch

[Hans Gilde]

I really can't see why it would now cache something that wasn't cached
before. Maven isn't using multiple threads, so the cache is essentially a
Map. The only change I made ensures that the Tags in the Map are available
for GC as soon as the Script that they belong to becomes available. None of
that has anything to do with the behavior of the caching... I think.

But, I'm glad to hear that it works.

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Sunday, May 22, 2005 12:39 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hans Gilde wrote:

>Wait... strike this new patch. My old one should be fine. Now I'm jumping
to
>conclusions because I haven't looked at it for so long.
>
>Brett, what's being reused where it wasn't before? I would not expect this
>behavior.

I believe all it meant was that where before a tag was not cached, now
it was - so instead of allocating a new object, it reused it and I was
assuming a null value in a variable previously set by the tag.

It wasn't a problem to make the change in Maven. As for SVN - I applied
your previous patch to jelly.

I think everything is fine.

- - Brett

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkAzGOb5RoQhMkRMRAhEVAKCHiNmrBunZvWLVsQrfx8YNF1x1SQCffcHW
N2S0RO6DV78ZzM41T8d+yOs=
=P5zu
-END PGP SIGNATURE-


-
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]

[logging] detecting logging libs

[Simon Kitching]

On Sun, 2005-05-22 at 21:01 +0100, robert burrell donkin wrote:
> On Sun, 2005-05-22 at 10:43 +, [EMAIL PROTECTED] wrote:
> 
> 
> 
> >  protected boolean isJdk13LumberjackAvailable() {
> >  
> > +// note: the algorithm here is different from isLog4JAvailable.
> > +// I think isLog4JAvailable is correctsee bugzilla#31597
> 
> +1
> 
> could do with going through all the isAvailable's and checking whether
> their algorithms are correct. however, i suspect that brian's approach
> will be needed to deal correctly with some circumstances. if no one
> feels like volunteering should probably record this in bugzilla so we
> don't lose track...

If by "brian's approach" you mean creating an instance of the logger
class in order to test whether that logging lib is *really* available, I
agree. 

Not only is it more reliable, but it's a cleaner solution; currently the
LogFactoryImpl class is making *assumptions* about what classes the
various logging adapters depend on. That information should be only in
the logging adapter class.

The only problem with creating an instance of the logger is that we
would have to pass a category string to the logger constructor, and
therefore must build an assumption into LogFactoryImpl about what
category names are valid for the underlying logger. Can we assume that
an empty string is a valid category for all logger libraries? Can we
assume that "apache" or "org.apache.commons.logging" are valid category
strings? Perhaps some loggers only accept valid URLs as
categories...yes, I'm playing devil's advocate a bit here. I guess we
could always say that the writer of the logging adapter is required to
return a valid logger instance for category "", even if that is not
normally a category that is valid to the underlying library.

Regards,

Simon



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

Re: [logging] proposed design for 1.0.5

[Brian Stansberry]

--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> =
> I would like to propose the following for jcl 1.0.5:


> 
> (e) 
> That we remove the weakref stuff that was added
> since 1.0.4 (sorry,
> Brian!). 

No problem -- I realize as I write this that I've been
subconsciously waiting for the ax to fall ever since
you posted about the memory leak problem in beanutils
;)

Teaches me (yet again) not to try to solve a problem
without fully understanding the problem domain.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: [logging] added diagnostics

[Simon Kitching]

On Sun, 2005-05-22 at 21:05 +0100, robert burrell donkin wrote:

> however, having wasted too many hours trying to arguing about
> performance, if i get a minute, i'll go through and put checks around
> calls just to stop any arguments later. (don't think that they'll be too
> much negative performance impact from it.)

I'm not concerned about performance. What I'm concerned about is code
readability. JCL is pretty difficult to comprehend at the moment, and I
didn't want to make it any harder for new developers by adding yet more
lines of code to the file when they wouldn't have any measurable effect
on any benchmark.

It's not hugely important to me though, so if anyone feels a strong
desire to add
  if (isDiagnosticsEnabled()) {
  }
to the code several dozen times to gain a few milliseconds on webapp/app
startup then I can live with it.

Regards,

Simon


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

DO NOT REPLY [Bug 29423] - [collections] Open Patch 25553 for version 3.0

[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=29423


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 01:09 ---
This bug is moving into the NeedInfo state.

This means that we need more info (in this case a small test case, preferably
junit) that can demonstrate the problem.

-- 
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 34368] - [collections] Compile Errors when Importing in VAJ 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=34368





--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 01:07 ---
(In reply to comment #10)
My mistake, it didn't sound like you would accept a patch either.


-- 
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 32204] - [collections] ExtendedProperties#convertProperties doesn't inherit defaults.

[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=32204


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 01:05 ---
Patches applied, thanks

-- 
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: r171380 - in /jakarta/commons/proper/collections/trunk: RELEASE-NOTES.html project.xml src/java/org/apache/commons/collections/ExtendedProperties.java src/test/org/apache/commons/collections/TestExtendedProperties.java

[scolebourne]

Author: scolebourne
Date: Sun May 22 16:04:44 2005
New Revision: 171380

URL: http://svn.apache.org/viewcvs?rev=171380&view=rev
Log:
Fix ExtendedProperties.convertProperties to pickup any default parent 
configuration
bug 32204, from Shinobu Kawai

Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
jakarta/commons/proper/collections/trunk/project.xml

jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/ExtendedProperties.java

jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestExtendedProperties.java

Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?rev=171380&r1=171379&r2=171380&view=diff
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Sun May 22 
16:04:44 2005
@@ -73,6 +73,7 @@
 BoundedFifoBuffer/CircularFifoBuffer - Fix serialization to work in case 
where buffer serialized when full [31433]
 BoundedFifoBuffer - Fix iterator remove bug causing ArrayIndexOutOfBounds 
error [33071]
 IteratorChain.remove() - Fix to avoid IllegalStateException when one of 
the underlying iterators is a FilterIterator [34267]
+ExtendedProperties.convertProperties() - Fix to handle default properties 
maps correctly [32204]
 
 
 JAVADOC

Modified: jakarta/commons/proper/collections/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/project.xml?rev=171380&r1=171379&r2=171380&view=diff
==
--- jakarta/commons/proper/collections/trunk/project.xml (original)
+++ jakarta/commons/proper/collections/trunk/project.xml Sun May 22 16:04:44 
2005
@@ -207,6 +207,9 @@
   Nissim Karpenstein
 
 
+  Shinobu Kawai
+
+
   Mohan Kishore
 
 

Modified: 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/ExtendedProperties.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/ExtendedProperties.java?rev=171380&r1=171379&r2=171380&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/ExtendedProperties.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/ExtendedProperties.java
 Sun May 22 16:04:44 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2001-2004 The Apache Software Foundation
+ *  Copyright 2001-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.
@@ -137,6 +137,7 @@
  * @author Janek Bogucki
  * @author Mohan Kishore
  * @author Stephen Colebourne
+ * @author Shinobu Kawai
  */
 public class ExtendedProperties extends Hashtable {
 
@@ -1610,6 +1611,9 @@
 
 /**
  * Convert a standard properties class into a configuration class.
+ * 
+ * NOTE: From Commons Collections 3.2 this method will pick up
+ * any default parent Properties of the specified input object.
  *
  * @param props  the properties object to convert
  * @return new ExtendedProperties created from props
@@ -1617,12 +1621,12 @@
 public static ExtendedProperties convertProperties(Properties props) {
 ExtendedProperties c = new ExtendedProperties();
 
-for (Enumeration e = props.keys(); e.hasMoreElements();) {
+for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
 String s = (String) e.nextElement();
 c.setProperty(s, props.getProperty(s));
 }
 
 return c;
 }
-
+
 }

Modified: 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestExtendedProperties.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestExtendedProperties.java?rev=171380&r1=171379&r2=171380&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestExtendedProperties.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestExtendedProperties.java
 Sun May 22 16:04:44 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2001-2004 The Apache Software Foundation
+ *  Copyright 2001-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.
@@ -18,6 +18,7 @@
 import java.io.ByteArrayInputStream;
 import java.i

Re: [logging] a candidate explanation for "Log4JLogger does not implement Log"

[Brian Stansberry]

--- robert burrell donkin
<[EMAIL PROTECTED]> wrote:

> On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching
> wrote:
> > Hi All,
> > 
> > I've been working for quite a while now to try to
> figure out why users
> > of JCL have been getting the "Log4JLogger does not
> implement Log"
> > message.
> > 
> > I think I've finally really understood the cause.
> If this is really
> > obvious to everyone, please let me down gently :-)
> 
> one thing which i have learnt from working with JCL
> over the years is
> that nothing is ever obvious :)
> 
> more than anything we need clear explanations of
> what happens and why. 
> 

+1.

I understood (and had since forgotten) from working
with Ceki Gulcu's JCL analysis that the problems
happened when code loaded a parent loaded tried to log
with the TCCL in effect, but your  discussion of why
such a call would be made -- outside a test fixture :)
-- makes the real world issue much clearer (and easier
to remember).


>> Ok, so what is the solution?
>
>
>i would like to split this question into two. 
>
>
>i believe (as indicated in the analysis document)
that the correct
>behaviour in these cases is for JCL to recognise that
log4j is not
>viable (for this configuration) and default to
java.util logging. this
>is a little unsatisfactory but i don't see a
reasonable technical
>solution for these configuration.
>

One unsatisfactory aspect is that instead of throwing
an exception with a nice message and stack trace,
logging would mysteriously be done using an unexpected
logging library.  But Simon's recent work on adding
diagnostics should help mitigate this drawback.

>
>the other question (which i think is what simon
addresses below) is how
>can JCL provide a solution for a user who needs a
similar configuration
>but who is willing to choose to deploy JCL slightly
differently.
>
>
>> (1)
>> Well, ensuring that the logging adapters are
deployed via the parent
>> classloader *only* is one. That fixes the problem,
as Log4JLogger et.
>> al. always bind to the same Log interface that
LogFactory binds to. 
>> 
>> The downside is:
>>  * It means that the logging library must also be
deployed via the
>>parent classloader, even when there *are* no
other classes in the
>>parent classloader that trigger this problem (ie
ones that use JCL
>>and that the webapp is going to call into).
>> 
>>Having the logging library loaded via the parent
classloader means
>>that dumb logging libraries may not be able to
find their config
>>files. 
>> 
>>Some logging libs may be smart enough to look
for their
>>resource files via the context classloader. And
in some cases the
>>logging *adapter* class might be able to tell
the logging lib
>>where the config file is. Assuming we can rely
on (or trick) the
>>logging lib to correctly handle
per-context-classloader location
>>of their config files, all should be well.
>
>
>-1
>
>seems like giving away too much for a corner case
>
>
>> (2)
> I think we could simply change the distribution
bundles. The root
>> problem appears to be to me that the adapters
(Log4JLogger et al) are
>> bundled with a Log implementation. If we produced a
jar that included
>> Log4JLogger et al. but *without* the Log class, the
problem should be
>> solved. The rule would then be:
>>   * if the parent loader has commons-logging.jar or
>> commons-logging-api.jar, then deploy 
>> commons-logging-adapters.jar in the child,
together with the
>> actual logging library.
>>   * otherwise, deploy commons-logging.jar in the
child
>> (or commons-logging-api.jar +
commons-logging-adapters.jar)
>
>
>this approach to these kinds of configuration is the
one i was thinking
>of earlier when i suggested that we might need an
implementations only
>distribution. a reasonable user could then adjust the
deployment so that
>the implementations were in the child and the api in
the parent.
>
>
>> (3)
>> Maybe we should just do away with LogFactoryImpl's
attemp to load a log
>> adapter via the context classloader. It does enable
the setup of having
>> commons-logging-api.jar in the parent and
commons-logging.jar in the
>> child, but it fails badly if any other class in the
parent classloader
>> uses JCL and is called by the webapp. Is this
benefit worth the pain?
>
>
>no
>
>
>but there is a variation (that i have discussed with
richard
>previously). the particular problem situation can be
diagnosed (a log
>class loaded from the context should have an
incompatible classloader).
>when the implementation is not viable, rather than
throw an exception
>JCL could try to load the class with the same name
from it's
>classloader.
>
>
>i think that brian's patch does something which
though implemented
>differently has the same net result.  
>
>
>however, i don't think that either of these
approaches would actually
>work in this case: log4j is not visible to the parent
classloader. i do
>think that something along these lines will be needed
for the exotic
>cla

Re: [math] setSubMatrix patch

[Rodrigo di Lorenzo Lopes]

Phil Steitz wrote:
Oh! I´m sorry Phil .. Yes, I am still learning.
I will send a unit test and BigMatrix versions soon.

Thank for all,
Rodrigo


Rodrigo,

Thanks for the patch!

It would be great if you could also add some unit tests for this and
provide an implementation and tests for the BigMatrix versions.

Also, its a little easier to keep things organized if you attach the
patch to the bugzilla ticket.  Just open the report here
 then use the
"Create a New Attachment" link to add the patch.

Phil

-
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]

DO NOT REPLY [Bug 34368] - [collections] Compile Errors when Importing in VAJ 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=34368





--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 00:50 ---
As I wrote before, if a patch is supplied, then we may apply it. But I agree
with James that this is low priority. [collections] has very limited committer
time, so sometimes we have to pick and choose which tasks to do.

-- 
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: [math] Making PRNG pluggable in o.a.c.m.random classes

[Phil Steitz]

Thanks, Brent.
As I write up the docs, I am thinking about adding one more thing,
which I would apprecate feedback on.  I mentioned above that the
RandomGenerator / AbstractRandomGenerator provided a generic facility
for replacing java.util.random.  Recompilation is still required,
however, to use this.  I am thinking now that it might be useful to
add a class that *extends* java.util.Random to wrap a RandomGenerator
to make it possible to do this in a binary compatible way.  Does this
make sense?

Phil

On 5/21/05, Brent Worden <[EMAIL PROTECTED]> wrote:
> The implementation looks good an a lot less heftier than what I was
> anticipating.
> 
> Good work,
> 
> Brent Worden
> 
> > -Original Message-
> > From: Phil Steitz [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, May 15, 2005 1:39 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [math] Making PRNG pluggable in o.a.c.m.random classes
> >
> > I committed the changes described above.  Feedback welcome.
> > I tested adapting and integration a RngPack generator.
> > Adaptor for Mersenne Twister looks like this (base adaptor
> > for all RngPack generators would be similar):
> >
> > /**
> >  * AbstractRandomGenerator based on RngPack RanMT generator.
> >  */
> > public class TestRngPackGenerator extends AbstractRandomGenerator {
> >
> > private RanMT random = new RanMT();
> >
> > public void setSeed(long seed) {
> >random = new RanMT(seed);
> > }
> >
> > public double nextDouble() {
> > return random.raw();
> > }
> >
> > public double nextGaussian() {
> > return random.gaussian();
> > }
> >
> > public int nextInt(int n) {
> > return random.choose(n);
> > }
> >
> > public boolean nextBoolean() {
> > return random.coin();
> > }
> > }
> >
> > I will update the user guide to include this and other
> > examples assuming all are OK with these changes.
> >
> > Phil
> >
> > -
> > 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: [math][proposal] Release math 1.1

[Phil Steitz]

I just added a wiki page presenting a Release Plan here:

http://wiki.apache.org/jakarta-commons/math/1%2e1ReleasePlan

Pls add anything that I missed and mark items "DONE" as they are completed. 

thx,

Phil

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

[Jakarta-commons Wiki] Update of "math/1.1ReleasePlan" by PhilSteitz

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by PhilSteitz:
http://wiki.apache.org/jakarta-commons/math/1%2e1ReleasePlan

--
+ ## page was renamed from 1.1ReleasePlan
  ## page was renamed from DotOneReleasePlan
  = Release Plan For Commons Math 1.1 =
  

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

[Jakarta-commons Wiki] Update of "Math" by PhilSteitz

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by PhilSteitz:
http://wiki.apache.org/jakarta-commons/Math

--
  
  = Version 1.1 Release plan =
  
- DotOneReleasePlan - release plan for 1.1.
+ 1.1ReleasePlan - release plan for 1.1.
  

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

[Jakarta-commons Wiki] Update of "1.1ReleasePlan" by PhilSteitz

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by PhilSteitz:
http://wiki.apache.org/jakarta-commons/1%2e1ReleasePlan

--
+ ## page was renamed from DotOneReleasePlan
  = Release Plan For Commons Math 1.1 =
  
  == Background ==

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

[Jakarta-commons Wiki] Update of "DotOneReleasePlan" by PhilSteitz

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by PhilSteitz:
http://wiki.apache.org/jakarta-commons/DotOneReleasePlan

New page:
= Release Plan For Commons Math 1.1 =

== Background ==

This is a maintenance release including bug fixes and some enhancements. 

== Status ==

In progress



= Pre Release Tasks =

== Coding ==
 * Complete `SubMatrix` implementation requested in Pr 35007
 * Add `TestUtils` class including factory methods as requested in Pr 32663

=== Documentation ===
 * Run linkcheck to verify links in javadoc and user guide
 * Add documentation in user guide showing how PRNG pluggability works

=== Javadoc ===

 * Add since tags to all methods introduced since 1.0 release
 * Improve `WeibullDistributionImpl` javadoc
 * Review all javadoc for accuracy and completeness

=== Check Compatibility ===

This release should be binary compatible with the 1.0 release, including 
serialization

== RC(s) ==

 * Once tasks above a completed, create MATH_1.1_RC1 branch and roll a full RC
 * Repeat for n=2, 3, ... until all are happy (see below :-)

== Release Notes ==

Create a text file based on the content of changes.xml, name this 
`ReleaseNotes.txt` and add to release.  Would be great to have a 
commons-standard way to do this.

== Release Vote(s) ==

If no objections are raised on problems reported with an RC after two days, a 
VOTE thread will be kicked off.  If problems are reported during the vote, 
these will be fixed and a new RC will be made available and a new VOTE 
initiated.  This process will iterate until we have had a successful VOTE 
thread extend for 72 hours.
  

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

Re: [logging] added diagnostics

[robert burrell donkin]

On Sun, 2005-05-22 at 22:48 +1200, Simon Kitching wrote:
> Hi,
> 
> As you have probably seen from the commit messages, I have added
> diagnostic output to LogFactory.java and LogFactoryImpl.java. I hope the
> implementation meets with everyone's agreement; if not, I'll fix it.

everything seems fine at first glance. the more eyes on it, the better
(though) - so don't anyone else feel shy to speak up :)

> 
> You will note that in most places I have not bothered to put
>   if (isDiagnosticsEnabled()) {
>   }
> around calls, even when strings are being concatenated. This is because
> *none* of these calls are on the critical path. Diagnostics are only
> ever output when a LogFactoryImpl is created for the first time, and I
> can't see much benefit in optimising code that is called once per
> classloader

i agree about your assessment about performance. 

however, having wasted too many hours trying to arguing about
performance, if i get a minute, i'll go through and put checks around
calls just to stop any arguments later. (don't think that they'll be too
much negative performance impact from it.)

- robert


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

Re: svn commit: r171301 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java

[robert burrell donkin]

On Sun, 2005-05-22 at 10:43 +, [EMAIL PROTECTED] wrote:



>  protected boolean isJdk13LumberjackAvailable() {
>  
> +// note: the algorithm here is different from isLog4JAvailable.
> +// I think isLog4JAvailable is correctsee bugzilla#31597

+1

could do with going through all the isAvailable's and checking whether
their algorithms are correct. however, i suspect that brian's approach
will be needed to deal correctly with some circumstances. if no one
feels like volunteering should probably record this in bugzilla so we
don't lose track...

- robert


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

Re: svn commit: r171301 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java

[robert burrell donkin]

On Sun, 2005-05-22 at 10:43 +, [EMAIL PROTECTED] wrote:
> Author: skitching



> @@ -368,24 +461,48 @@
>  String logClassName = getLogClassName();
>  
>  // Attempt to load the Log implementation class
> +//
> +// Question: why is the loginterface being loaded dynamically?
> +// Isn't the code below exactly the same as this?
> +//Class logInterface = Log.class;
> +

i suspect that the reason it was coded this way is there are some
security gymnastics performed and it's the LogFactory (rather than
LogFactoryImpl) class classloader that is used to load the class. 

i'm not convinced that this actually serves any useful purpose: in the
end the instance created will have to be cast to Log as referenced by
LogFactoryImpl. 

- robert


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

[Jakarta-commons Wiki] Update of "Math" by PhilSteitz

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by PhilSteitz:
http://wiki.apache.org/jakarta-commons/Math

The comment on the change is:
Added ReleasePlan

--
  
  MathWishList - list of requested features.
  
+ = Version 1.1 Release plan =
+ 
+ DotOneReleasePlan - release plan for 1.1.
+ 

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

DO NOT REPLY [Bug 34368] - [collections] Compile Errors when Importing in VAJ 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=34368





--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 21:33 ---
(In reply to comment #8)

Because its the right thing to do ? David has noted a problem that he has with
commons-collections, and he outlines the solution which is neither complicated
nor does break anything. He probably would even create a patch to fix it (there
shouldn't be too much problematic usages of Map.Entry). So why should we refuse
to incorporate it ?


-- 
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: r171363 - in /jakarta/commons/proper/math/trunk: project.xml xdocs/index.xml xdocs/navigation.xml

[psteitz]

Author: psteitz
Date: Sun May 22 12:29:45 2005
New Revision: 171363

URL: http://svn.apache.org/viewcvs?rev=171363&view=rev
Log:
Minor site updates
* Changed scm link to point to cgi
* Edited down content on main page
* Added direct link to svn on nav
* Changed download link to point directly to math page

Modified:
jakarta/commons/proper/math/trunk/project.xml
jakarta/commons/proper/math/trunk/xdocs/index.xml
jakarta/commons/proper/math/trunk/xdocs/navigation.xml

Modified: jakarta/commons/proper/math/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/project.xml?rev=171363&r1=171362&r2=171363&view=diff
==
--- jakarta/commons/proper/math/trunk/project.xml (original)
+++ jakarta/commons/proper/math/trunk/project.xml Sun May 22 12:29:45 2005
@@ -47,7 +47,7 @@
   
/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}/
   
 
scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk
-
http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk
+
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/math/trunk/
   
   
 

Modified: jakarta/commons/proper/math/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/xdocs/index.xml?rev=171363&r1=171362&r2=171363&view=diff
==
--- jakarta/commons/proper/math/trunk/xdocs/index.xml (original)
+++ jakarta/commons/proper/math/trunk/xdocs/index.xml Sun May 22 12:29:45 2005
@@ -28,22 +28,6 @@
 
   

-The Java programming language and the math extensions in
-Commons Lang provide implementations for only the most basic
-mathematical algorithms. Routine development tasks such as
-computing basic statistics or solving a system of linear equations
-require components not available in Java or Commons Lang.
-   
-   
-Most basic mathematical or statistical algorithms are available in
-open source implementations, but to assemble a simple set of
-capabilities one has to use multiple libraries, many of which have
-more restrictive licensing terms than the ASF. In addition, many
-of the best open source implementations (e.g. the R statistical
-package) are either not available in Java or require large support
-libraries and/or external dependencies to work.
-   
-   
 Commons Math is a library of lightweight, self-contained
 mathematics and statistics components addressing the most common
 problems not available in the Java programming language or Commons
@@ -76,30 +60,18 @@
  
 

-   
-
- Yes - I know that it should be commons-maths. But think of all the
- bandwidth saved by losing that 's' ;)
-
-   
   
   

 
-  The latest release of Commons Math is available for download here:
-  
- 
- http://jakarta.apache.org/site/binindex.cgi#commons-math";>
- 1.0 Binary 
- 
- http://jakarta.apache.org/site/sourceindex.cgi#commons-math";>
- 1.0 Source 
-  
+  The latest release of Commons Math is available for download
+  http://jakarta.apache.org/site/downloads/downloads_commons-math.cgi";>
+  here
 


 
- Nightly builds are built once a day from the current CVS HEAD.
+ Nightly builds are built once a day from the current SVN HEAD.
  This is (nearly) the lastest code and so should be treated with
  caution!
 

Modified: jakarta/commons/proper/math/trunk/xdocs/navigation.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/xdocs/navigation.xml?rev=171363&r1=171362&r2=171363&view=diff
==
--- jakarta/commons/proper/math/trunk/xdocs/navigation.xml (original)
+++ jakarta/commons/proper/math/trunk/xdocs/navigation.xml Sun May 22 12:29:45 
2005
@@ -38,6 +38,8 @@
   
   
   
+  http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/math/trunk"/>
   http://wiki.apache.org/jakarta-commons/MathWishList"/>
 



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

DO NOT REPLY [Bug 34368] - [collections] Compile Errors when Importing in VAJ 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=34368





--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 21:26 ---
So, why should we change code to work around a broken compiler in a tool that
very few folks use anymore?

-- 
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 34690] - [collections] Concurrent modification in FastArrayList

[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=34690


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 21:26 ---
I have committed a change to avoid calling previousIndex().

I can't test it using GNU Classpath easily, so I'll close the call, and leave it
to be re-opened if necessary.

-- 
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: r171361 - /jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html

[scolebourne]

Author: scolebourne
Date: Sun May 22 12:24:47 2005
New Revision: 171361

URL: http://svn.apache.org/viewcvs?rev=171361&view=rev
Log:
Group bug fixes into collection types

Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html

Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?rev=171361&r1=171360&r2=171361&view=diff
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Sun May 22 
12:24:47 2005
@@ -62,17 +62,17 @@
 
 FastArrayList - Fix iterators and views to work better in multithreaded 
environments
 FastArrayList - Fix iterator remove where ConcurrentModificationException 
not as expected [34690]
-BoundedFifoBuffer/CircularFifoBuffer - Fix serialization to work in case 
where buffer serialized when full [31433]
-BoundedFifoBuffer - Fix iterator remove bug causing ArrayIndexOutOfBounds 
error [33071]
-MultiHashMap.remove(key, item) - Was returning the item even when nothing 
was removed [32366]
 SetUniqueList.set(int,Object) - Destroyed set status in certain 
circumstances [33294]
 AbstractLinkedMap.init() - Now calls createEntry() to create the map entry 
object [33706]
-BeanMap.initialize() - Internal variable now correctly initialised with 
only write methods that actually exist [15895]
-TransformedMap.putAll - Now allows putAll of an empty map [34686]
 AbstractHashedMap deserialization - Fix to prevent doubling of internal 
data array [34265]
+AbstractHashedMap initialization - Fix to setup threshold correctly, 
improving performance [35012]
+BeanMap.initialize() - Internal variable now correctly initialised with 
only write methods that actually exist [15895]
+MultiHashMap.remove(key, item) - Was returning the item even when nothing 
was removed [32366]
 Flat3Map.equals() - Fix to make flat mode comparison actually work 
[34917]
+TransformedMap.putAll - Now allows putAll of an empty map [34686]
+BoundedFifoBuffer/CircularFifoBuffer - Fix serialization to work in case 
where buffer serialized when full [31433]
+BoundedFifoBuffer - Fix iterator remove bug causing ArrayIndexOutOfBounds 
error [33071]
 IteratorChain.remove() - Fix to avoid IllegalStateException when one of 
the underlying iterators is a FilterIterator [34267]
-AbstractHashedMap initialization - Fix to setup threshold correctly, 
improving performance [35012]
 
 
 JAVADOC



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

svn commit: r171360 - in /jakarta/commons/proper/collections/trunk: RELEASE-NOTES.html src/java/org/apache/commons/collections/FastArrayList.java src/test/org/apache/commons/collections/TestFastArrayList.java

[scolebourne]

Author: scolebourne
Date: Sun May 22 12:23:04 2005
New Revision: 171360

URL: http://svn.apache.org/viewcvs?rev=171360&view=rev
Log:
Simplify code in iterator remove to avoid incorrect 
ConcurrentModificationException
bug 34690, from Guilhem Lavaux at Kaffe

Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html

jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/FastArrayList.java

jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestFastArrayList.java

Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?rev=171360&r1=171359&r2=171360&view=diff
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Sun May 22 
12:23:04 2005
@@ -61,6 +61,7 @@
 BUG FIXES
 
 FastArrayList - Fix iterators and views to work better in multithreaded 
environments
+FastArrayList - Fix iterator remove where ConcurrentModificationException 
not as expected [34690]
 BoundedFifoBuffer/CircularFifoBuffer - Fix serialization to work in case 
where buffer serialized when full [31433]
 BoundedFifoBuffer - Fix iterator remove bug causing ArrayIndexOutOfBounds 
error [33071]
 MultiHashMap.remove(key, item) - Was returning the item even when nothing 
was removed [32366]

Modified: 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/FastArrayList.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/FastArrayList.java?rev=171360&r1=171359&r2=171360&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/FastArrayList.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/FastArrayList.java
 Sun May 22 12:23:04 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2001-2004 The Apache Software Foundation
+ *  Copyright 2001-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.
@@ -1305,7 +1305,7 @@
 }
 get().remove(lastReturnedIndex);
 expected = list;
-iter = get().listIterator(previousIndex());
+iter = get().listIterator(lastReturnedIndex);
 lastReturnedIndex = -1;
 }
 

Modified: 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestFastArrayList.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestFastArrayList.java?rev=171360&r1=171359&r2=171360&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestFastArrayList.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestFastArrayList.java
 Sun May 22 12:23:04 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2001-2004 The Apache Software Foundation
+ *  Copyright 2001-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.
@@ -16,7 +16,9 @@
 package org.apache.commons.collections;
 
 import java.util.ArrayList;
+import java.util.ConcurrentModificationException;
 import java.util.List;
+import java.util.ListIterator;
 
 import junit.framework.Test;
 
@@ -50,6 +52,113 @@
 FastArrayList fal = new FastArrayList();
 fal.setFast(false);
 return (fal);
+}
+
+public void testConcurrentModification_alwaysFast() {
+FastArrayList list = new FastArrayList();
+list.setFast(true);
+list.add("a");
+list.add("b");
+list.add("c");
+ListIterator iter = list.listIterator();
+assertEquals("a", iter.next());
+assertEquals("b", iter.next());
+iter.remove();  // checking for no ConcurrentModificationException
+assertEquals("c", iter.next());
+assertEquals(false, iter.hasNext());
+assertEquals("c", iter.previous());
+assertEquals("a", iter.previous());
+assertEquals(false, iter.hasPrevious());
+}
+
+public void testConcurrentModification_alwaysFastModError() {
+FastArrayList list = new FastArrayList();
+list.setFast(true);
+list.add("a");
+list.add("b");
+list.add("c");
+ListIterator iter = list.listIterator();
+assertEquals("a", iter.next());
+assertEquals("b", iter.next());
+list.remove(1);
+

DO NOT REPLY [Bug 34368] - [collections] Compile Errors when Importing in VAJ 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=34368





--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 21:22 ---
This is most likely a bug in VAJ. A subclass inherits all accessible
(non-private) inner classes from its basetype just like it would inherit
accessible fields. Thus for subtypes of Map, its perfectly valid to access Entry
directly without the starting "Map.".

-- 
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 34368] - [collections] Compile Errors when Importing in VAJ 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=34368





--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 21:14 ---
My question is why is this a compile error with one compiler and not with
another?  Which one is correct by the JLS?

-- 
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: [logging] a candidate explanation for "Log4JLogger does not implement Log"

[robert burrell donkin]

On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching wrote:
> Hi All,
> 
> I've been working for quite a while now to try to figure out why users
> of JCL have been getting the "Log4JLogger does not implement Log"
> message.
> 
> I think I've finally really understood the cause. If this is really
> obvious to everyone, please let me down gently :-)

one thing which i have learnt from working with JCL over the years is
that nothing is ever obvious :)

more than anything we need clear explanations of what happens and why. 

> The problem is not the *presence* of JCL in the parent or child
> classloader paths. The problem is the presence of code that *calls*
> LogFactory.getLog in classes in the parent classpath. When webapp code
> calls into such a class with the context classloader set, that triggers
> the problem.

+1

now that the demonstration code has been fixed, it is clear that (for
conventional classloader setups anyway) there's only one substantive
case that is missing. that's a lot better than things appeared a while
ago. 

> The problem only ever occurs when child-first classloading is selected
> (ironic, considering my recent arguments in favour of this feature).
> 
> 1.
> 
> A class in the webapp has a symbolic reference to a method on a class
> that is present only in the parent classpath. That class is therefore
> located by the parent classloader. Java's resolution mechanism then
> requires that the classes referenced by it (LogFactory, LogFactoryImpl,
> Log) are loaded via the same classloader.

+1

> 2.
> 
> The webapp code then actually calls the above method. Context
> classloader is set to the webapp classloader. Control flows through the
> called method to LogFactory, to LogFactoryImpl. LogFactoryImpl then
> dynamically loads Log4JLogger from the context classpath, ending up
> with an implementation from the child classloader.
> 
> However Log4JLogger has a symbolic reference to the Log class (because
> it implements it). And the java rules specify that such references are
> resolved via the classloader that loaded the referencing classes. So the
> Log class that Log4JLogger references is loaded via the child
> classloader.

+1

> 3.
> 
> The LogFactoryImpl class then tries to cast Log4JLogger to its version
> of Log and fails, because the Log class was loaded via different
> classloaders.

+1

there is actually no reason why the cast actually needs to be performed
to diagnose this condition: all that's required is to check the
classloader used to load the implementation class.

> ===
> A minor variant is where the object in the parent classloader that calls
> LogFactory.getLog is created by the container and passed as a parameter
> to the webapp (eg an implementation of ServletContext). The basic
> behaviour is the same, though.
> ===
> 
> Ok, so what is the solution?

i would like to split this question into two. 

i believe (as indicated in the analysis document) that the correct
behaviour in these cases is for JCL to recognise that log4j is not
viable (for this configuration) and default to java.util logging. this
is a little unsatisfactory but i don't see a reasonable technical
solution for these configuration.

the other question (which i think is what simon addresses below) is how
can JCL provide a solution for a user who needs a similar configuration
but who is willing to choose to deploy JCL slightly differently.

> (1)
> Well, ensuring that the logging adapters are deployed via the parent
> classloader *only* is one. That fixes the problem, as Log4JLogger et.
> al. always bind to the same Log interface that LogFactory binds to. 
> 
> The downside is:
>  * It means that the logging library must also be deployed via the
>parent classloader, even when there *are* no other classes in the
>parent classloader that trigger this problem (ie ones that use JCL
>and that the webapp is going to call into).
> 
>Having the logging library loaded via the parent classloader means
>that dumb logging libraries may not be able to find their config
>files. 
> 
>Some logging libs may be smart enough to look for their
>resource files via the context classloader. And in some cases the
>logging *adapter* class might be able to tell the logging lib
>where the config file is. Assuming we can rely on (or trick) the
>logging lib to correctly handle per-context-classloader location
>of their config files, all should be well.

-1

seems like giving away too much for a corner case

> (2)
> I think we could simply change the distribution bundles. The root
> problem appears to be to me that the adapters (Log4JLogger et al) are
> bundled with a Log implementation. If we produced a jar that included
> Log4JLogger et al. but *without* the Log class, the problem should be
> solved. The rule would then be:
>   * if the parent loader has commons-logging.jar or
> commons-logging-api.jar, then deploy 
> commons-logging-adapters.jar in the child, together with the
>

DO NOT REPLY [Bug 34368] - [collections] Compile Errors when Importing in VAJ 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=34368





--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 20:13 ---
While I'm not directly affected (havn't used VAJ for several years now), I find
this solution unsatisfactory. For one, while this may be a temporary solution it
would be a solution, and when the code gets broken again for VAJ, then another
bug can be raised.
Also, there is at least one easy way to make certain that Entry gets only used
as Map.Entry, and that is by incorporating PMD (http://pmd.sourceforge.net) in
the build process and write a specific rule for Map.Entry. Perhaps David would
volunteer to write this rule ?

WDYT ?
Tom


-- 
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: [RESULT][VOTE][VFS] Promote commons-vfs to commons proper

[Martin Cooper]

On 5/20/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote:



> It would be nice if someone could check if my (imario) svn access rights
> for commons-proper are correctly setup and if needed adjust them.
> And if one could add VFS to the bugzilla components list I would be
> thankful too.

Both done.

--
Martin Cooper


> Thanks!
> Mario
> 
> 
> -
> 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]

DO NOT REPLY [Bug 34446] - [collection] Map filter with MapUtils.predicatedMap feature request

[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=34446


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 20:04 ---
The solution to your problem would appear to be:

Map reqParams;
CollectionUtils.filter(reqParams.keySet(), filterPredicate);


The deeper request in this call is covered by the proposal to add FilteredMap to
[collections].

Closing this call as wontfix.

-- 
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 34368] - [collections] Compile Errors when Importing in VAJ 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=34368


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 20:00 ---
The committers of [collections] have no simple means to test this problem (no
VAJ). While we would consider applying a cvs diff -u patch, that would only be a
temporary fix. As soon as we edited the file to make some other fix, the chances
are that we would break the VAJ code again.

Closing as wontfix.

-- 
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 33190] - [collections] Facility for passing an Iterator object into the 'View' part of an MVC framework

[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=33190


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 19:53 ---
There may on some occaisions be good reasons to use a design like this. However,
as a broad design, it has flaws which this discussion have highlighted. As such,
we would be uncomfortable suggesting it in a widespread package like 
[collections].

Closing as wontfix.

-- 
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 35012] - [collections] AbstractHashedMap: initial threshold too conservative

[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=35012


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 19:49 ---
Patch applied, thanks

-- 
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: r171349 - in /jakarta/commons/proper/collections/trunk: RELEASE-NOTES.html project.xml src/java/org/apache/commons/collections/map/AbstractHashedMap.java src/test/org/apache/commons/collections/map/TestHashedMap.java

[scolebourne]

Author: scolebourne
Date: Sun May 22 10:48:56 2005
New Revision: 171349

URL: http://svn.apache.org/viewcvs?rev=171349&view=rev
Log:
Fix AbstractHeashedMap initialization to calculate correct threshold
bug 35012, by Christian Siefkes

Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
jakarta/commons/proper/collections/trunk/project.xml

jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/AbstractHashedMap.java

jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestHashedMap.java

Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?rev=171349&r1=171348&r2=171349&view=diff
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Sun May 22 
10:48:56 2005
@@ -71,6 +71,7 @@
 AbstractHashedMap deserialization - Fix to prevent doubling of internal 
data array [34265]
 Flat3Map.equals() - Fix to make flat mode comparison actually work 
[34917]
 IteratorChain.remove() - Fix to avoid IllegalStateException when one of 
the underlying iterators is a FilterIterator [34267]
+AbstractHashedMap initialization - Fix to setup threshold correctly, 
improving performance [35012]
 
 
 JAVADOC

Modified: jakarta/commons/proper/collections/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/project.xml?rev=171349&r1=171348&r2=171349&view=diff
==
--- jakarta/commons/proper/collections/trunk/project.xml (original)
+++ jakarta/commons/proper/collections/trunk/project.xml Sun May 22 10:48:56 
2005
@@ -285,6 +285,9 @@
   Jon Schewe
 
 
+  Christian Siefkes
+
+
   Michael Smith
 
 

Modified: 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/AbstractHashedMap.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/AbstractHashedMap.java?rev=171349&r1=171348&r2=171349&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/AbstractHashedMap.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/AbstractHashedMap.java
 Sun May 22 10:48:56 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2003-2004 The Apache Software Foundation
+ *  Copyright 2003-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.
@@ -56,6 +56,7 @@
  *
  * @author java util HashMap
  * @author Stephen Colebourne
+ * @author Christian Siefkes
  */
 public class AbstractHashedMap extends AbstractMap implements IterableMap {
 
@@ -145,8 +146,8 @@
 throw new IllegalArgumentException("Load factor must be greater 
than 0");
 }
 this.loadFactor = loadFactor;
-this.threshold = calculateThreshold(initialCapacity, loadFactor);
 initialCapacity = calculateNewCapacity(initialCapacity);
+this.threshold = calculateThreshold(initialCapacity, loadFactor);
 this.data = new HashEntry[initialCapacity];
 init();
 }

Modified: 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestHashedMap.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestHashedMap.java?rev=171349&r1=171348&r2=171349&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestHashedMap.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestHashedMap.java
 Sun May 22 10:48:56 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2001-2004 The Apache Software Foundation
+ *  Copyright 2001-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.
@@ -58,7 +58,16 @@
 assertEquals(map.size(), cloned.size());
 assertSame(map.get("1"), cloned.get("1"));
 }
-
+
+public void testInternalState() {
+HashedMap map = new HashedMap(42, 0.75f);
+assertEquals(0.75f, map.loadFactor, 0.1f);
+assertEquals(0, map.size);
+assertEquals(64, map.data.length);
+assertEquals(48, map.threshold);
+assertEquals(0, map.modCount);
+}
+
 //public void testCreate() throws Exception {
 // 

svn commit: r171347 - in /jakarta/commons/proper/collections/trunk: RELEASE-NOTES.html src/java/org/apache/commons/collections/iterators/IteratorChain.java src/test/org/apache/commons/collections/iterators/TestIteratorChain.java

[scolebourne]

Author: scolebourne
Date: Sun May 22 10:27:34 2005
New Revision: 171347

URL: http://svn.apache.org/viewcvs?rev=171347&view=rev
Log:
Bug 34267: IteratorChain.remove() in combination with FilterIterator

Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html

jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/iterators/IteratorChain.java

jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/iterators/TestIteratorChain.java

Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?rev=171347&r1=171346&r2=171347&view=diff
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Sun May 22 
10:27:34 2005
@@ -70,6 +70,7 @@
 TransformedMap.putAll - Now allows putAll of an empty map [34686]
 AbstractHashedMap deserialization - Fix to prevent doubling of internal 
data array [34265]
 Flat3Map.equals() - Fix to make flat mode comparison actually work 
[34917]
+IteratorChain.remove() - Fix to avoid IllegalStateException when one of 
the underlying iterators is a FilterIterator [34267]
 
 
 JAVADOC

Modified: 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/iterators/IteratorChain.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/iterators/IteratorChain.java?rev=171347&r1=171346&r2=171347&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/iterators/IteratorChain.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/iterators/IteratorChain.java
 Sun May 22 10:27:34 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 1999-2004 The Apache Software Foundation
+ *  Copyright 1999-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.
@@ -280,7 +280,7 @@
  */
 public void remove() {
 lockChain();
-if( currentIterator == null ) {
+if (currentIterator == null) {
 updateCurrentIterator();
 }
 lastUsedIterator.remove();

Modified: 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/iterators/TestIteratorChain.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/iterators/TestIteratorChain.java?rev=171347&r1=171346&r2=171347&view=diff
==
--- 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/iterators/TestIteratorChain.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/iterators/TestIteratorChain.java
 Sun May 22 10:27:34 2005
@@ -1,5 +1,5 @@
 /*
- *  Copyright 2001-2004 The Apache Software Foundation
+ *  Copyright 2001-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.
@@ -19,11 +19,10 @@
 import java.util.Iterator;
 import java.util.List;
 import java.util.NoSuchElementException;
-import java.util.LinkedList;
 
 import junit.framework.Test;
 import junit.framework.TestSuite;
-import org.apache.commons.collections.PredicateUtils;
+
 import org.apache.commons.collections.IteratorUtils;
 import org.apache.commons.collections.Predicate;
 



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

Re: [RESULT][VOTE][VFS] Promote commons-vfs to commons proper

[Mario Ivankovits]

Dion Gillard wrote:

Bugzilla or Jira?
 

I prefer to stick to bugzilla.

---
Mario


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

DO NOT REPLY [Bug 35012] New: - [collections] AbstractHashedMap: initial threshold too conservative

[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=35012

   Summary: [collections] AbstractHashedMap: initial threshold too
conservative
   Product: Commons
   Version: 3.1
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Collections
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The (int initialCapacity, float loadFactor) constructor of
org.apache.commons.collections.map.AbstractHashedMap calculates the initial
resize too threshold conservatively, based on the requested initial capacity
instead of the actually chosen initial capacity (which is round up to the next
power of too). This could be fixed switching two lines to calculating the
initial threshold after rounding up the capacity instead of before:

--- AbstractHashedMap.java  2005-05-22 17:04:23.0 +0200
+++ AbstractHashedMap-patched.java  2005-05-22 17:08:46.0 +0200
@@ -147,4 +147,4 @@
 this.loadFactor = loadFactor;
-this.threshold = calculateThreshold(initialCapacity, loadFactor);
 initialCapacity = calculateNewCapacity(initialCapacity);
+this.threshold = calculateThreshold(initialCapacity, loadFactor);
 this.data = new HashEntry[initialCapacity];

A map with an requested capacity of 600 and a load factor of 0.75, will start
with an initial array of length 1024. Without the fix, the array will be resized
for the first time as soon as there are 450 entries, i.e. the array is less than
45% filled instead of the 75% suggested by the load factor.

-- 
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: [logging] test cases 1 to 4

[robert burrell donkin]

On Fri, 2005-05-20 at 15:54 +0200, Ceki Gülcü wrote:
> At 03:05 5/19/2005, Simon Kitching wrote:
> >On Wed, 2005-05-18 at 17:58 +0200, Ceki Gülcü wrote:
> > > Robert et al.,
> > >
> > > Your test cases are self-describing and easy to follow. One can hardly
> > > appreciate the work gone into putting in place something as delicate
> > > and tedious as these test cases. Well done!
> >Yes, I think so to.
> >
> > >
> > > At first I was a bit puzzled that the static branch failed, and
> > > initially suspected the correctness of the test cases. However, given 
> > > their
> > > construction, it is only normal for the static branch of tests 1 to 4
> > > to fail. It actually goes to prove that the test framework is doing
> > > its job correctly.
> > >
> > > However, if the intention was to compare dynamic binding versus
> > > static-binding, the setup of tests 1 to 4 is unrepresentative of the
> > > static-binding case, unless I am missing the point. For tests 1-4, you
> > > are demonstrating the fact that a parent class loader cannot see
> > > resources available to its children. Isn't this kind of obvious?
> >
> >I think it's more a complete table of all combinations of 4 or 5
> >different factors. Not all of them are sensible, but it means that the
> >combinations are all complete.
> 
> In  static  binding,  the  facade  and the  implementation  are  bound
> together at compile  time. So it's totally impossible  for client code
> to find the facade but  not the implementation. Actually, if that were
> not  the  case,  that  is  if   the  facade  was  found  and  not  the
> implementation, or if the implementation was found but not the facade,
> it would mean that something seriously wrong had gone within the JVM.
> 
> If the intent is to permute through all the possible combinations,
> then that's a different matter. Wouldn't it be actually better to test
> combinations that make sense?

no: this really hits to the heart of the problem. one man's corner cases
are another's fatal flaws. the only chance of making real progress is to
enumerate and deal with all possible combinations, not just those that
make sense to developers here. 

of course, fixing combinations which make no sense is another matter: in
some cases, it might be better to note that they not reasonable and
describe the consequences... 

> >As I note here, scenarios 17 and 21 (plus a few others) are simply not
> >reasonable ones, and can be ignored from any reasonable assessment of
> >whether a particular logging setup works or not.
> >http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111578975603542&w=2
> >
> >It would be nice to note in the associated document which are scenarios
> >that can be ignored as not reasonable.
> >
> >My document here
> >http://people.apache.org/~skitching/jcl-req.txt
> >describes a specific scenario where I think static binding doesn't work
> >(see b4) - and it is quite a reasonable requirement I think. Of course
> >there are many scenarios where static binding is a very good solution.
> >I'm thinking that the best solution is one where the user can select
> >static binding for the majority of cases (ie deploy a simple jar that is
> >statically bound), but drop in a more dynamic factory class in the
> >problem scenario.
> 
> Selecting static binding for the majority of cases but having a way to 
> dynamically select factory sounds very promising.

+1

being able to use both static and dynamic binding solutions where each
makes more sense has (for a while) been my only hope of making real
progress. i have some ideas that have been building for a while but i
think maybe slf4j would be a better forum to address them. (i should be
more active for the next few weeks that i have been for last month.) i'd
also like to hear simon's proposals first.

- robert


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

Re: [RESULT][VOTE][VFS] Promote commons-vfs to commons proper

[Dion Gillard]

Bugzilla or Jira?

On 5/20/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hello!
> 
> After one week here is the positive result of the voting:
> 
> Move out of sandbox:
> 
> +1 Simon Kitching
> +1 Stephen Colebourne
> +1 Dion Gillard
> +0 Mark Diggory
> +0 Phil Steitz
> +1 Mario Ivankovits
> 
> User votes:
> +1 Filip
> 
> Cut Release 1.0:
> 
> +0 Stephen Colebourne
> +1 Dion Gillard
> +0 Mark Diggory
> +0 Phil Steitz
> +1 Mario Ivankovits
> 
> User votes:
> +1 Filip
> 
> 
> So I will start to move VFS out of the sandbox, but maybe I havent
> enough spare time until Monday next week. I have to paint my living room
> this weekend :-)
> Simon already reviewed the required documents and made some of them svn
> aware, I will pick them up and see what happens.
> 
> It would be nice if someone could check if my (imario) svn access rights
> for commons-proper are correctly setup and if needed adjust them.
> And if one could add VFS to the bugzilla components list I would be
> thankful too.
> 
> 
> Thanks!
> Mario
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
http://www.multitask.com.au/people/dion/

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

Issue in CLI package

[Igor Laberov]

Hi all,
I'm working with GnuParser from CLI and other commons libraries, you did
great work!

Just some issue.
Recently, I encountered with the following problem: if I pass arguments
like "-n m -m foo", the parser tries to interpret 'm' as an option,
though it was passed as argument value. When I've examinated the code,
noticed that in Parser.processArgs() "var" (i.e. value) is tried to be
found in Options list (and it is found, since Options.hasOption()
doesn't care about '-', but only about length). 
It seems to me as a bug. Since change that I intended to do in Parser
will influence PosixParser (and may be other parsers too), it looks more
safe to change GnuParser (see attached diff) - override
Parser.processArgs() function, so argument value will not be interpreted
as an option.
What do you think?

Thanks,
Igor Laberov,
Qlusters Inc.



/*
 * $Header: /home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/GnuParser.java,v 1.10 2002/09/19 22:59:43 jkeyes Exp $
 * $Revision: 1.10 $
 * $Date: 2002/09/19 22:59:43 $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999-2001 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Commons", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 *
 */
package org.apache.commons.cli;

import java.util.Arrays;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;
import java.util.ListIterator;

/**
 * The class GnuParser provides an implementation of the 
 * [EMAIL PROTECTED] Parser#flatten(Options,String[],boolean) flatten} method.
 *
 * @author John Keyes (john at integralsource.com)
 * @see Parser
 * @version $Revision: 1.10 $
 */
public class GnuParser extends Parser {

/** holder for flattened tokens */
private ArrayList tokens = new ArrayList();

/**
 * Resets the members to their original state i.e. remove
 * all of tokens entries.
 */
private void init() {
tokens.clear();
}

/**
 * This flatten method does so using the following rules:
 * 
 *  If an [EMAIL PROTECTED] Option} exists for the first character of 
 *  the arguments entry AND an [EMAIL PROTECTED] Option} 
 *  does not exist for the whole argument then
 *  add the first character as an option to the processed tokens
 *  list e.g. "-D" and add the rest of the entry to the also.
 *  Otherwise just add the token to the processed tokens list.
 *  
 * 
 * 
 */
protected String[] flatten( Options options, 
String[] a

RE: [i18n] Remaining issues

[Arnaud HERITIER]

My 2 cents, 

> 
> * Synchronize Maven (project.xml) and Ant (build.xml).
> Proposed fix: Add jcoverage test coverage to build.xml. (I 
> have EMMA test coverage with Ant locally). This might imply 
> adding jcoverage jars to a lib dir.

To simplify your devs,

- You can generate a minimal build.xml from maven with the ant plugin :
http://maven.apache.org/reference/plugins/ant/

- You can use the jcoverage report in maven :
http://maven.apache.org/reference/plugins/jcoverage/

Arnaud




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

svn commit: r171303 - /jakarta/commons/proper/commons-build/trunk/xdocs/releases/index.xml

[skitching]

Author: skitching
Date: Sun May 22 03:55:51 2005
New Revision: 171303

URL: http://svn.apache.org/viewcvs?rev=171303&view=rev
Log:
Note the mirroring doc is probably obsolete.

Modified:
jakarta/commons/proper/commons-build/trunk/xdocs/releases/index.xml

Modified: jakarta/commons/proper/commons-build/trunk/xdocs/releases/index.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/xdocs/releases/index.xml?rev=171303&r1=171302&r2=171303&view=diff
==
--- jakarta/commons/proper/commons-build/trunk/xdocs/releases/index.xml 
(original)
+++ jakarta/commons/proper/commons-build/trunk/xdocs/releases/index.xml Sun May 
22 03:55:51 2005
@@ -46,10 +46,9 @@
 
 
 Preparations For A Release
-Mirroring For The First Time
 Cutting The Release - Step By 
Step
-
 Versioning Guidelines
+Mirroring For The First Time (may be 
obsolete)
 
 
 



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

[logging] added diagnostics

[Simon Kitching]

Hi,

As you have probably seen from the commit messages, I have added
diagnostic output to LogFactory.java and LogFactoryImpl.java. I hope the
implementation meets with everyone's agreement; if not, I'll fix it.

You will note that in most places I have not bothered to put
  if (isDiagnosticsEnabled()) {
  }
around calls, even when strings are being concatenated. This is because
*none* of these calls are on the critical path. Diagnostics are only
ever output when a LogFactoryImpl is created for the first time, and I
can't see much benefit in optimising code that is called once per
classloader

Regards,

Simon


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

svn commit: r171301 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java

[skitching]

Author: skitching
Date: Sun May 22 03:43:52 2005
New Revision: 171301

URL: http://svn.apache.org/viewcvs?rev=171301&view=rev
Log:
Added internal diagnostics

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java?rev=171301&r1=171300&r2=171301&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
 Sun May 22 03:43:52 2005
@@ -76,6 +76,8 @@
  */
 public LogFactoryImpl() {
 super();
+initDiagnostics();  // method on this object
+logDiagnostic("Instance created.");
 }
 
 
@@ -109,6 +111,11 @@
 
 
 /**
+ * The string prefixed to every message output by the logDiagnostic method.
+ */
+private String diagnosticPrefix;
+
+/**
  * Configuration attributes.
  */
 protected Hashtable attributes = new Hashtable();
@@ -160,7 +167,6 @@
 
 // - Public Methods
 
-
 /**
  * Return the configuration attribute with the specified name (if any),
  * or null if there is no such attribute.
@@ -250,6 +256,7 @@
  */
 public void release() {
 
+logDiagnostic("Releasing all known loggers");
 instances.clear();
 }
 
@@ -287,13 +294,90 @@
 }
 
 
+// -- 
+// Static Methods
+//
+// These methods only defined as workarounds for a java 1.2 bug;
+// theoretically none of these are needed.
+// -- 
+
+/**
+ * Gets the context classloader.
+ * This method is a workaround for a java 1.2 compiler bug.
+ */
+protected static ClassLoader getContextClassLoader() throws 
LogConfigurationException {
+return LogFactory.getContextClassLoader();
+}
+
+/**
+ * Workaround for bug in Java1.2; in theory this method is not needed.
+ * See LogFactory.isInternalLoggingEnabled.
+ */
+protected static boolean isDiagnosticsEnabled() {
+return LogFactory.isDiagnosticsEnabled();
+}
+
+/**
+ * Workaround for bug in Java1.2; in theory this method is not needed.
+ * See LogFactory.getClassLoader.
+ */
+protected static ClassLoader getClassLoader(Class clazz) {
+return LogFactory.getClassLoader(clazz);
+}
+
 // -- Protected Methods
 
+/**
+ * Calculate and cache a string that uniquely identifies this instance,
+ * including which classloader the object was loaded from.
+ * 
+ * This string will later be prefixed to each "internal logging" message
+ * emitted, so that users can clearly see any unexpected behaviour.
+ * 
+ * Note that this method does not detect whether internal logging is 
+ * enabled or not, nor where to output stuff if it is; that is all
+ * handled by the parent LogFactory class. This method just computes
+ * its own unique prefix for log messages.
+ */
+private void initDiagnostics() {
+// It would be nice to include an identifier of the context classloader
+// that this LogFactoryImpl object is responsible for. However that
+// isn't possible as that information isn't available. It is possible
+// to figure this out by looking at the logging from LogFactory to
+// see the context & impl ids from when this object was instantiated,
+// in order to link the impl id output as this object's prefix back to
+// the context it is intended to manage.
+Class clazz = this.getClass();
+ClassLoader classLoader = getClassLoader(clazz);
+diagnosticPrefix = clazz.getName() + "@" + classLoader.toString() + 
":";
+}
 
+/**
+ * Output a diagnostic message to a user-specified destination (if the
+ * user has enabled diagnostic logging).
+ * 
+ * @param msg
+ */
+protected void logDiagnostic(String msg) {
+if (isDiagnosticsEnabled()) {
+logRawDiagnostic(diagnosticPrefix + msg);
+}
+}
 
 /**
  * Return the fully qualified Java classname of the [EMAIL PROTECTED] Log}
  * implementation we will be using.
+ * 
+ * This method looks in the following places:
+ * 
+ * Looks for an attribute LOG_PROPERTY or LOG_PROPERTY_OLD in the 
+ * "attributes" associated with this class, as set earlier by method 
+ * setAttribute.
+ * Looks for a property LOG_PRO

svn commit: r171300 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

[skitching]

Author: skitching
Date: Sun May 22 03:43:06 2005
New Revision: 171300

URL: http://svn.apache.org/viewcvs?rev=171300&view=rev
Log:
Added internal diagnostics

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?rev=171300&r1=171299&r2=171300&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 Sun May 22 03:43:06 2005
@@ -21,6 +21,8 @@
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.InputStreamReader;
+import java.io.PrintStream;
+import java.io.FileOutputStream;
 import java.lang.reflect.InvocationTargetException;
 import java.lang.reflect.Method;
 import java.security.AccessController;
@@ -80,6 +82,34 @@
 "META-INF/services/org.apache.commons.logging.LogFactory";
 
 /**
+ * The name of the property used to enable internal commons-logging
+ * diagnostic output, in order to get information on what logging
+ * implementations are being discovered, what classloaders they 
+ * are loaded through, etc.
+ * 
+ * If a system property of this name is set then the value is
+ * assumed to be the name of a file. The special strings
+ * STDOUT or STDERR (case-sensitive) indicate output to
+ * System.out and System.err respectively.
+ */
+public static final String DIAGNOSTICS_DEST_PROPERTY =
+"org.apache.commons.logging.diagnostics.dest";
+
+/**
+ * When null (the usual case), no diagnostic output will be
+ * generated by LogFactory or LogFactoryImpl. When non-null,
+ * interesting events will be written to the specified object.
+ */
+private static PrintStream diagnosticsStream = null;
+
+/**
+ * A string that gets prefixed to every message output by the
+ * logDiagnostic method, so that users can clearly see which
+ * LogFactory class is generating the output.
+ */
+private static String diagnosticPrefix;
+
+/**
  * Setting this system property value allows the Hashtable 
used to store
  * classloaders to be substituted by an alternative implementation.
  * 
@@ -133,10 +163,9 @@
 /**
  * Protected constructor that is not available for public use.
  */
-protected LogFactory() { 
+protected LogFactory() {
 }
-
-
+
 // - Public Methods
 
 
@@ -247,6 +276,21 @@
  */
 protected static LogFactory nullClassLoaderFactory = null;
 
+/**
+ * Create the hashtable which will be used to store a map of
+ * (context-classloader -> logfactory-object). Version 1.2+ of Java
+ * supports "weak references", allowing a custom Hashtable class
+ * to be used which uses only weak references to its keys. Using weak
+ * references can fix memory leaks on webapp unload in some cases (though
+ * not all). Version 1.1 of Java does not support weak references, so we
+ * must dynamically determine which we are using. And just for fun, this
+ * code also supports the ability for a system property to specify an
+ * arbitrary Hashtable implementation name.
+ * 
+ * Note that the correct way to ensure no memory leaks occur is to ensure
+ * that LogFactory.release(contextClassLoader) is called whenever a 
+ * webapp is undeployed.
+ */
 private static final Hashtable createFactoryStore() {
 Hashtable result = null;
 String storeImplementationClass 
@@ -260,9 +304,16 @@
 
 } catch (Throwable t) {
 // ignore
-   if (!WEAK_HASHTABLE_CLASSNAME.equals(storeImplementationClass)) 
{
-   // if the user's trying to set up a custom 
implementation, give a clue
-   System.err.println("[ERROR] LogFactory: Load of custom 
hashtable failed");
+if (!WEAK_HASHTABLE_CLASSNAME.equals(storeImplementationClass)) {
+   // if the user's trying to set up a custom implementation, 
give a clue
+   if (isDiagnosticsEnabled()) {
+   // use internal logging to issue the warning
+   logDiagnostic("[ERROR] LogFactory: Load of custom 
hashtable failed");
+   } else {
+   // we *really* want this output, even if 
diagnostics weren't
+// explicitly enabled by the user.
+   System.err.println("[ERROR] LogFactory: Load of 
custom hashtable failed");
+   }
}

[Jakarta-commons Wiki] Update of "Betwixt/0.6.1ReleasePlan" by RobertBurrellDonkin

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by RobertBurrellDonkin:
http://wiki.apache.org/jakarta-commons/Betwixt/0%2e6%2e1ReleasePlan

--
  
  == Status ==
  
- Just an idea ;)
+ Under preparation
  
  
  
@@ -14, +14 @@

  
  Review of issues in Bugzilla and formulation of a plan about which will be 
address for this release.
  
- == CVS ==
+ == SVN ==
  
- A new release branch (RELEASE_0_6_1_BRANCH) will be taken. This will allow 
development to continue on CVS HEAD without risking the stability of the 
release. Release candidates and releases will be cut from this branch. 
+ A new release branch (RELEASE_0_6_1_BRANCH) will be taken. This will allow 
development to continue on HEAD without risking the stability of the release. 
Release candidates and releases will be cut from this branch. 
  
  == Documentation ==
  
@@ -39, +39 @@

  
  Up to [:Betwixt]
  
- 

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

DO NOT REPLY [Bug 35004] - [collections] Supplement collections with contribution

[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=35004


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Supplement collections with |[collections] Supplement
   |contribution|collections with
   ||contribution




-- 
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 35007] - [math] setSubMatrix method

[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=35007


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|setSubMatrix method |[math] setSubMatrix method




-- 
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: r171297 - /jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml

[skitching]

Author: skitching
Date: Sun May 22 02:02:16 2005
New Revision: 171297

URL: http://svn.apache.org/viewcvs?rev=171297&view=rev
Log:
Add link to subversion bug#.

Modified:
jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml

Modified: jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml?rev=171297&r1=171296&r2=171297&view=diff
==
--- jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml 
(original)
+++ jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml Sun 
May 22 02:02:16 2005
@@ -171,7 +171,7 @@
date-based indexes for all modifications prior to that import, even in 
non-related
parts of the repository (the indexes are repository-wide). So while 
dates are
reported correctly in "svn log" output, only revision numbers should be 
used with
-   the -r option.
+   the -r option. See issue #752 in the subversion issue tracker at 
tigris.org.

 
 



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

DO NOT REPLY [Bug 34289] - [configuration] FileChangedReloadingStrategy fails to properly detect file change

[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=34289





--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 10:29 ---
Created an attachment (id=15116)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15116&action=view)
Substitute for FileChangedReloadingStrategy which solves the problem for
Configuration 1.1

This class can be used as a replacement of FileChangedReloadingStrategy until a
version of Configuration which solves this bug is released.

-- 
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 34289] - [configuration] FileChangedReloadingStrategy fails to properly detect file change

[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=34289





--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 10:19 ---
Created an attachment (id=15115)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15115&action=view)
Add method containerFileURL to be used by FileChangedReloadingStrategy

I suggest adding a method called containerFileFromURL which converts the
specified URL to a file object which points to a file in the file system. If
the URL points directly to a file in the file system the returned object will
point to it, on the other side if it points to a file inside a JAR the returned
file object will point to the JAR file. If this fails, null is returned.


The original fileFromURL cannot be modified because it is used by
AbstractFileConfiguration and it expects to get be returned a file which the
configuration can be saved to.


-- 
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: r171286 - /jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml

[skitching]

Author: skitching
Date: Sun May 22 00:23:41 2005
New Revision: 171286

URL: http://svn.apache.org/viewcvs?rev=171286&view=rev
Log:
Document bug with subversion and dates in the -r option.

Modified:
jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml

Modified: jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml?rev=171286&r1=171285&r2=171286&view=diff
==
--- jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml 
(original)
+++ jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml Sun 
May 22 00:23:41 2005
@@ -164,6 +164,15 @@
 
 Please remember to spell check the release notes. Please break lines 
at 80 characters.
 
+   
+   IMPORTANT! At the current time, selecting by date in subversion 
within the
+   ASF repository isn't reliable. The reason is that imports of data from 
CVS
+   repositories into any part of the subversion repository stuffs 
up subversion's
+   date-based indexes for all modifications prior to that import, even in 
non-related
+   parts of the repository (the indexes are repository-wide). So while 
dates are
+   reported correctly in "svn log" output, only revision numbers should be 
used with
+   the -r option.
+   
 
 
 



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

[i18n] Remaining issues

[Mattias J]

Here is a list of what I think needs to be done before i18n is moved to 
proper/released as 1.0:


* If the id ("parent") exists, but the entry ("child") does not, the 
ResourceBundleMessageProvider throws an exception (erroneously claiming "No 
message entries found for bundle with key ..."), while the 
XMLMessageProvider returns null.
Proposed fix: Make all implementations of MessageProvider.getText() return 
null if message is not found and have MessageManager.getText() throw the 
Exception instead. We can then remove the try/catch in MessageManager.
Also consider renaming MessageProvider.getText() to 
MessageProvider.findText() to make this more obvious for implementors.


* The ResourceBundleMessageProvider and the XMLMessageProvider behave 
differently when an entry does not exist in a non-default language. With 
ResourceBundles, if there is an entry, say

  helloWorld.notTranslated=This entry is not translated to any other languages
that only exists in the default locale file, the entry will be included 
when calling getEntries() for *any* locale. Whereas for XML, only the 
entries defined for the given locale will be returned.
Proposed fix: First of all, I am not sure I personally think this needs 
fixing, since all the entries should normally be translated. Secondly, I 
don't know which behaviour I believe is most correct, but since we cannot 
change the implementation of ResourceBundle, the only option would be to 
make XMLMessageProvider (and any other MessageProvider) behave the same way 
as the ResourceBundleMessageProvider. If we decide this does not need to be 
fixed, we need to document the difference in behaviour somewhere (JavaDoc?).


* Consider the semi-circular dependency between MessageManager and the 
MessageProvider implementations. The implementations are used, via the 
interface, by the MessageManager and the MessageManager is used by the 
implementations for install/uninstall through static methods, and for 
internal error messages.

Proposed fix(es):
  1. Remove the static install/uninstall/update methods on the 
MessageProvider implementations.
  2. Move the MessageManager.INTERNAL_MESSAGES and the internal message 
keys to a utitly class, say I18nUtils. I have ideas for other stuff to put 
there too. Another alternative would be to consider whether we actually 
need these error messages in the MessageProvider implementations. As of the 
above proposal, at least the use of MessageManager.NO_MESSAGE_ENTRIES_FOUND 
should be moved to MessageManager instead.


* Consider the circular depency between the "org.apache.commons.i18n" and 
"org.apache.commons.i18n.bundles" packages. For example 
org.apache.commons.i18n.LocalizedException uses 
org.apache.commons.i18n.bundles.ErrorBundle which is a subclass to 
org.apache.commons.i18n.LocalizedBundle.
Proposed fix: Personally I think the org.apache.commons.i18n.bundles 
packages is a bit overkill; why not remove it altogether? Otherwise, move 
the LocalizedException/RuntimeException/Error into the bundles package (or 
another package such as "org.apache.commons.i18n.exceptions").


* The I18nTestSuite is not up to date.
Proposed fix: Remove it altogheter. There is no real use for it, and it is 
easy to forget to keep it up to date.


* Synchronize Maven (project.xml) and Ant (build.xml).
Proposed fix: Add jcoverage test coverage to build.xml. (I have EMMA test 
coverage with Ant locally). This might imply adding jcoverage jars to a lib 
dir.


* Create a database/JDBC MessageProvider to be used out-of-the-box, 
subclassed or as an example.

Proposed fix: I have it in my head, just need to find the time to code it.

* Unify XML indentation.
Proposed fix: We decided on 4 spaces, right? Then just use your favorite 
IDE to auto-indent *.xml.


* Consider renaming the file with the internal error messages. It is quite 
possible a user of the library would like to put their own error messages 
in messages.properties.
Proposed fix: Rename src/resources/messages*.properties to 
src/resources/i18n-messages*.properties and update corresponding code.


* Consider examples with qualified entries.
Proposed fix: Create code example that use my modification with qualified 
provider/namespace/source.


* Consider adding check style plugin in project.xml and fix whatever it 
reports.





  Mattias Jiderhamn
  Expert Systems

  Mail: 
[EMAIL PROTECTED]

  Web: www.expertsystem.se
  Skype: mattiasj78