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.
To answer your question, it goes back to my original statement. I think
we should not be patching with hardcoding for other APIs. Why? Because
we will undoubtably run into this with other packages in time. The next
commons-[insert your package here] that implements a similar technique,
then are we to do another hardcode? Once we start hardcoding others'
APIs, then we start to become responsible for the fixes if they don't
work right. The mere fact that the author of this package advocated
removal from the web-inf/lib directory, in and of itself, is a clear
warning that we are patching of others' issues. Minimally we should
allow the user to make the final decision of whether he/she wants
delegation to the server classes or not. IMHO...I would rather give
more control to the user and let them decide to exclude it. I don't
think that decision should be forced by us. But this is a semi-short
term solution...read the answer to your next question below.
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"?
I agree and I think David Jencks' email on this (as well as yours and my
email discussions) may be the ultimate solution. The problem is
essentially due to our classloader being too permissive about access. I
think you pointed this out earlier, and you and I had consensus on this.
The really short term solution is to hard code the commons-logging
package. The semi-short term solution is a plan based exclusion list.
The long term is to fix the class loaders. Do we agree on this?
Jeff
Thanks,
Aaron
