geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: [jira] Commented: (GERONIMO-518) Deploying Struts app fails on Logging ClassCastException
Date Sat, 01 Oct 2005 17:09:03 GMT
On 10/1/05, Jeff Genender <jgenender@savoirtech.com> wrote:
> Yes.  Lets make a more real scenario.  Lets say I write...not my own
> logging, but my own factory to do whatever, that needs package access to
> the o.a.c.l because something is protect in there.  With our hard code,
> I cannot use my class.  By creating an exclusionary list, I can exclude
> packages and classes, but allow my new class through.

OK, I believe that if you create some new classes in the same
org.apache.commons.logging package and don't modify any existing
commons-logging packages and then use *only* parent-first class
loading then you could manage to load your custom classes.  Just like
if you added a new class to javax.servlet, in the absence of package
loading restrictions, you could then load the class javax.servlet.Foo
from your web app.

However, I don't think it's necessary for us to support this scenario.
 I'm comfortable saying that if people want to provide their own
commons logging implementations or whatever then they should do it in
a different package.

If someone shows up with a compelling reason -- something really
useful that their app depends on and requires access to package-level
stuff in commons logging, OK, we should reconsider.

But in the mean time, let's just forcibly exclude the commons logging
package.  I think eliminating all possible bug reports caused by
reading commons logging code in WEB-INF/lib is worth the down side of
not allowing the scenario you present, at least until that compelling
reason shows up.

As you said on IRC, hopefully we'll move on to a better class loader
arrangement or drop commons-logging before that need to reconsider
rolls around.

Thanks,
   Aaron

Mime
View raw message