How about Struts JARs at the EAR level? Wouldn't that be loaded (by
default anyway) by a higher-level classloader than individual apps and
shared across all WARs in the EAR? Not sure that's quite the same thing
though (and I'm basing this on Websphere, which as we all know has some
of the most convoluted classloader schemes around, version 5.x and prior
at least).
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
Rene Gielen wrote:
Very interesting article, indeed. Both WW and S2 use static loggers, as
it was always considered best practice...
On the other hand, the problem only applies if a shared classloader is
used, and I can hardly imagine a setup where struts jars are deployed
eg. in $CATALINA/commons/lib rather than being provided with the
deployed webapp. Is there any situation where we would recommend sharing
s1/s2/xw among applications, or where it really makes sense? Even if
calling Logger.getLog is not a real performance killer, I would prefer
to call it not on every single object instance creation if there is no
serious, non-exotic reason...
Regards,
Rene
Paul Benedict schrieb:
Simon was correct and I believe this should be addressed. Does anyone
have objections or advice on this issue? How about you WW guys? Have
you been doing the same static logging?
Wendy Smoak wrote:
On 7/6/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
Has anyone ever read this?
http://wiki.apache.org/jakarta-commons/Logging/StaticLog
Did you check the archives? Simon mentioned it well over a year ago,
with no replies:
http://www.nabble.com/commons-logging-and-static-log-members-t1244201.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
