David Jencks wrote:
With our current classloaders I think we need to include commons logging
in the exclusion list for the reasons Aaron explains.
Agreed - there never was any argument here. Already done..GERONIMO-518
patches have been applied and committed to HEAD and M5.
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.
+1. ;-) I look forward to working on this stuff.
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.
I don't agree with you about not removing the hard coded part. What if
I write my own patches to commons-logging to fix some of these issues
and do my own specialized logging. I then need the o.a.c.l package
structure, as a user. By hardcoding this, you have taken that ability
for me to do this...my jars will never get used. I am against
this...this takes away complete control from the user to patch and make
their own o.a.c.l versions. What happens then? Do we tell the user
"too bad"...or should we give them a choice of excluding it via a
configuration, so they can roll their own o.a.c.l library?
IMHO...
1) Hard code now (M5)
2) Remove hard code and create an exclusions list (1.0)
3) Remove exclusions list and fix the classloaders (Post 1.0)
For number 2, we could easily create a warning if the user has
commons-logging in the web-inf/lib and its not excluded. But lets give
the user a choice. This takes us out of the loop completely from a
support perspective.
thanks
david jencks
