Tomcat and log4j (was: I am new and I am lost ...)

[Paul Glezen <pg...@atdial.net>]

Ceki Gülcü wrote:
> 

> Tomcat 3.x does not use log4j. However, as far as I know, Tomcat 4.0, or more precisely Catalina, the Servlet container for Servlet API Specification 2.3, has opted to use log4j internally. I'll double check this shortly.
> 
> The Tomcat API provides hooks to use different logging package then the one provided by tomcat internally. I have not used this extension facility extensions myself. However, I intend to study it in the near future.
> 

I'm not so sure that Tomcat (or any other kind of app server) using
log4j is a good thing. It was this very situation that got me to
investigate log4j in the first place.  I was using IBM's Component
Broker which uses JRAS (an ancient version of IBM's JLOG).  At first I
was happy that I was getting a log package for free.  JRAS was there by
virtue of my app running in Component Broker.

But as new versions of JRAS came out, I realized I couldn't use them
without risking an incompatibility with Component Broker (which relied
on an earlier version).  I was essentially stuck with whatever version
my appserver was using.  Since logging tools tend to release more often
than app servers, this significantly compromised the logging
effectiveness.  By using a tool like log4j that is not part of the app
server, I can choose to upgrade (or choose not to) whenever I want.  I
can also tweak the code for certain specific needs without having to
worry about impact to the app server.

- Paul
-- 
Beware of bugs in the above code.  I have
only proved it correct, not tried it.
-Don Knuth

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

Re: Tomcat and log4j (was: I am new and I am lost ...)

[Anders Kristensen <ak...@dynamicsoft.com>]

Paul Glezen wrote:
> 
> Ceki Gülcü wrote:
> >
> 
> > Tomcat 3.x does not use log4j. However, as far as I know, Tomcat 4.0, or more precisely Catalina, the Servlet container for Servlet API Specification 2.3, has opted to use log4j internally. I'll double check this shortly.
> >
> > The Tomcat API provides hooks to use different logging package then the one provided by tomcat internally. I have not used this extension facility extensions myself. However, I intend to study it in the near future.
> >
> 
> I'm not so sure that Tomcat (or any other kind of app server) using
> log4j is a good thing. It was this very situation that got me to
> investigate log4j in the first place.  I was using IBM's Component
> Broker which uses JRAS (an ancient version of IBM's JLOG).  At first I
> was happy that I was getting a log package for free.  JRAS was there by
> virtue of my app running in Component Broker.
> 
> But as new versions of JRAS came out, I realized I couldn't use them
> without risking an incompatibility with Component Broker (which relied
> on an earlier version).  I was essentially stuck with whatever version
> my appserver was using.  Since logging tools tend to release more often
> than app servers, this significantly compromised the logging
> effectiveness.  By using a tool like log4j that is not part of the app
> server, I can choose to upgrade (or choose not to) whenever I want.  I
> can also tweak the code for certain specific needs without having to
> worry about impact to the app server.

My understanding is that servlet API 2.3 addresses this issue by saying
that app class loaders NOT delegate class loading to the parent. The
following quote is from an article discussing changes in 2.3:

 
http://www.javaworld.com/javaworld/jw-01-2001/jw-0126-servletapi_p.html

<quote>
Class loaders

Here's a small change with a big impact: In API 2.3, a servlet container
a.k.a. the server) will ensure that classes in a Web application not be
allowed to see the server's implementation classes. In other words, the
class loaders should be kept separate. 

That doesn't sound like much, but it eliminates the possibility of a
collision between Web application classes and server classes. That had
become a serious problem because of XML parser conflicts. Each server
needs an XML parser to parse web.xml files, and many Web applications
these days also use an XML parser to handle reading, manipulation, and
writing of XML data. If the parsers supported different DOM or SAX
versions, that could cause an irreparable conflict. The separation of
class scope solves this issue nicely. 
</quote>

--
Anders Kristensen

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org