On 10/1/05, Jeff Genender <[EMAIL PROTECTED]> 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
