On Oct 1, 2005, at 7:34 AM, Aaron Mulder wrote:
On 9/29/05, Jeff Genender <[EMAIL PROTECTED]> wrote:
But I want to emphasize my discomfort with harcoding a commons package
into these loaders as it ultimately takes waya control from the user.
As
long as we can back this out and do a proper exclusion list in a
configurable plan, then I am cool with it.
Could you explain what you mean here? I think we've already seen that
in the case of commons logging, if you give that control to the user
(by exposing a list including commons logging) and they exercise it
(by removing commons logging from the list and including their own
commons logging JAR), they get a ClassCastException -- which is to
say, it doesn't work include your own commons logging and try to use
it instead of Geronimo's version. I think the only way to work around
that is a much more detailed restructuring of our ClassLoader
hierarchy. Do you have another proposal for "making commons logging
overridable"?
With our current classloaders I think we need to include commons
logging in the exclusion list for the reasons Aaron explains. There
may be a possibility of actually solving the problem with more
sophisticated classloaders that actually hide all the server classes
from the applications. From some conversations with Dain I think the
OSGI classloaders are capable of doing this, and I think he is looking
into the possibility of using them or something like them. I suspect
this would be a post 1.0 change however. For 1.0 I think the best we
can hope for is a configurable exclusion list, and my understanding is
that you should not be able to remove commons logging from the "fixed"
part of the exclusion list.
thanks
david jencks
