Aaron Mulder wrote:
For my part, I've never been arguing that this was a good way to
construct an application. I'm simply saying that if we as Geronimo
developers insist that people change their applications to work in
Geronimo, then we have a windmill issue. Even if we all agree that
putting commons logging in the WEB-INF/lib stinks, the fact is that
people do it, and do it for the most common web framework out there,
and those application do not break in other application servers. In
my opinion, RTFM is not the correct position for us to take.
I think it goes beyond RTFM...if the author is offering this as a
solution, I find it a pretty compelling argument.
Since we have an obvious workaround available (that is, making the
list of packages to exclude configurable, and putting commons logging
in there), why don't we plan to implement it?
Yes...I agree with you...it surely will not hurt to have a configurable
list of packages to bypass. Its a relief valve as a minimum and gives
the user a lot more power too...and it puts us a step ahead of the
competition ;-)
An alternative would be to restructure the class loaders so the client
cannot see any server classes including logging -- where the client
and server class loader trees are both rooted in a common class loader
with (more or less) only the spec JARs. I think this would be a great
approach, and I believe there was some wider interest in looking at
it, but it does not seem like a short-term (1.0-era) change.
This is a pretty good idea IMHO.
Aaron
On 9/30/05, Jeff Genender <[EMAIL PROTECTED]> wrote:
Bruce has shown us a great article that clearly explains the issues and
solutions:
http://www.qos.ch/logging/classloader.jsp
It describes this problem in detail...and it says (near the bottom) for
a solution:
"For Tomcat 5.0.27 and later,
<snip>
4. Do not include any other copies of commons-logging.jar and
log4j.jar in your web-applications' WEB-INF/lib/ directory.
<snip>
"
So...do we really want to hack up the classloader? Please read the
article..its fascinating. Thanks for the link, Bruce.
Jeff
Bruce Snyder wrote:
On 9/27/05, Kevan Miller <[EMAIL PROTECTED]> wrote:
Good point. I didn't notice that they were including Commons in their
WEB-INF/lib. I think this is related to the context-priority-classloader
discussion I brought up last week.
Section 9.7.2 of the Servlet spec specifies that for a J2EE product "The
container should not allow applications to override or access the
container's implementation classes". Depending on your definition of
"implementation classes", Geronimo's servlet classloaders permit a number of
"implementation classes" (including commons-logging) to be loaded from the
web app's context. As this situation points out, this can lead to a number
of problems.
The same section of the same spec also states the following:
'It is recommended also that the application class loader be
implemented so that classes and resources packaged within the WAR are
loaded in preference to classes and resources residing in
container-wide library JARs.'
Tomcat is a good exmaple of this in that it provides each webapp its
own class loader. And therein lies the reason I have always
recommended that each webapp should handle it's own logging (i.e.,
contain it's own logging jars and configuration files) *completely
separate* from the app server. I've seen far too many webapps that
utilize the app server's logging mechanism for an individual webapp.
IMO, this is simply wrong becuase it's using what I consider to be a
side effect as a feature.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
