It doesn't have to be an all or nothing game either. Obviously, even in
a shared library, instance loggers are not always appropriate. So it's
definitely on a class by class basis.
Frank W. Zammetti wrote:
FWIW, my opinion would be go ahead and change it... unless someone can
show where it would cause trouble, I'm in the better safe than sorry
camp. I know of a number of instances where I've seen Struts
installed in a shared way, either at EAR-level or something like
Tomcat's shared libs directory... I've never heard any trouble
reported from those cases though to be fair.
I think the performance/memory implications are the only thing that
might stop you from wanting to do this... perhaps some benchmarking is
in order?
Frank
Paul Benedict wrote:
I use WAS 6.0 at work and it took me 3 full days to figure out how to
get log4j working with it. Ugh. Yes, the software is an elephant.
Anyway, despite the fact that Struts 1 supports only static logging,
I believe this position could be evaluated. Correct me when wrong,
but the article states that instance logging should belong in
libraries that could be shared. What if a company wants to integrate
Struts or XWork into their application server software? Perhaps a
typically user wouldn't want to share Struts libraries in the parent
classloader, but what about in J2EE server? It's just a thought.
It wouldn't be too hard to convert the static loggers.
Paul
Frank W. Zammetti wrote:
Martin Cooper wrote:
It would be the same thing in the sense of the "direction" of the
class
loader, and I would expect the same screwy things to happen. And if
you're
using WebFear, then I'd fully expect other screwy things to happen
as well,
as a free bonus. ;-)
Hehe, I know *exactly* what you mean :) Between WS and RAD, my hair
is starting to look like Bill Clinton's, but at a much younger age!
Martin Cooper
Frank
---------------------------------------------------------------------
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]
