You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@voyager.apg.more.net> on 2000/08/13 14:48:19 UTC
Tomcat Logging
This may have been discussed before, but I don't recall seeing it,
or it may have been discussed before I started reading this list.
I was looking at
http://www.log4j.org/
a logging API for Java written by IBM and released under IBM's open source
license.
Has any consideration been given to using this for Tomcat logging?
There has been some discussion about making improvements to Tomcats
logging. Perhaps log4j could be implemented rather than spend alot
of time on our own code.
I know IBM contributes a great deal to the ASF, such as xerces.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Error with Session State?
Posted by "Kenneth R. Kress" <kk...@home.com>.
Sean,
What version are you using? It's broken in 3.1, but was fixed in 3.2b1.
I'm still using 3.1 and 3.2b1
Ken.
On Mon, 18 Sep 2000, you wrote:
> If this bug was reported and then closed, does it make this situation a pre-maturely
> closed bug or a feature? According to the Servlet 2.2 API javadocs, a call to
> getSession( boolean create ) returns "the HttpSession associated with this request
> or null if create is false and the request has no valid session." From what I can
> see, this call should return a new, valid session.
>
> "yhs@mimic.onesourcecorp.com" wrote:
>
> > On Fri, 15 Sep 2000, Sean McFadden wrote:
> >
> > > I have a servlet that calls this sequence of methods:
> > >
> > > HttpSession session = request.getSession( true );
> > >
> > > // insert business logic here, and if certain conditions occur:
> > > session.invalidate();
> > > session = request.getSession( true );
> > > session.setAttribute( "foo", "bar" );
> > ><SNIP>
> > > >From what I can make out, nothing is ever setting the serverSession in
> > > RequestImpl to null after StandardSession.invalidate() is called, so this
> > > method call does not produce a new serverSession as it should. Eyeballing the
> > > code sequence, it looks like the StandardSession knows that it's invalidated,
> > > and the StandardManager knows the session has been invalidated. But neither of
> > > these objects have a reference to the RequestImpl instance that "owns" the
> > > session, so they can't call setSession( null ). I haven't been able to quite
> > > make out how sessions get mapped to requests, or I would make submit a patch.
> > > It looks like this one will have to be taken care of by someone who knows a
> > > lot more about Tomcat internals than I do.
> > >
> > > Thanks,
> > > Sean
> > >
> >
> > i reported this many moons ago and it was filed as a bug which was closed
> > by someone. its the cookie handling bug...i dont think anyone solved it
> > but you can work around it. look at my old bug report. its not a very
> > interesting bug obviously. treat cookies and sessions as write once
> > read many type states and you should be ok. dont try to delete/modify.
> > -Ys-
> > yhs@mimic.onesourcecorp.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
Kenneth R. Kress kkress@home.com
Re: Error with Session State?
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Mon, 18 Sep 2000, Sean McFadden wrote:
> If this bug was reported and then closed, does it make this situation a pre-maturely
> closed bug or a feature? According to the Servlet 2.2 API javadocs, a call to
> getSession( boolean create ) returns "the HttpSession associated with this request
> or null if create is false and the request has no valid session." From what I can
> see, this call should return a new, valid session.
>
i'd call it a bug no one cares about. :)
eventually someone will get around to fixing it..i just worked around it
in my code which was easier to do than going thru tomcat and patching
it. cookies shouldnt be relied upon anyway..any client side data can be
tampered with. use only trusted server side variables for important
stuff.
-Ys-
yhs@mimic.onesourcecorp.com
Re: Error with Session State?
Posted by Sean McFadden <se...@wingateweb.com>.
If this bug was reported and then closed, does it make this situation a pre-maturely
closed bug or a feature? According to the Servlet 2.2 API javadocs, a call to
getSession( boolean create ) returns "the HttpSession associated with this request
or null if create is false and the request has no valid session." From what I can
see, this call should return a new, valid session.
"yhs@mimic.onesourcecorp.com" wrote:
> On Fri, 15 Sep 2000, Sean McFadden wrote:
>
> > I have a servlet that calls this sequence of methods:
> >
> > HttpSession session = request.getSession( true );
> >
> > // insert business logic here, and if certain conditions occur:
> > session.invalidate();
> > session = request.getSession( true );
> > session.setAttribute( "foo", "bar" );
> ><SNIP>
> > >From what I can make out, nothing is ever setting the serverSession in
> > RequestImpl to null after StandardSession.invalidate() is called, so this
> > method call does not produce a new serverSession as it should. Eyeballing the
> > code sequence, it looks like the StandardSession knows that it's invalidated,
> > and the StandardManager knows the session has been invalidated. But neither of
> > these objects have a reference to the RequestImpl instance that "owns" the
> > session, so they can't call setSession( null ). I haven't been able to quite
> > make out how sessions get mapped to requests, or I would make submit a patch.
> > It looks like this one will have to be taken care of by someone who knows a
> > lot more about Tomcat internals than I do.
> >
> > Thanks,
> > Sean
> >
>
> i reported this many moons ago and it was filed as a bug which was closed
> by someone. its the cookie handling bug...i dont think anyone solved it
> but you can work around it. look at my old bug report. its not a very
> interesting bug obviously. treat cookies and sessions as write once
> read many type states and you should be ok. dont try to delete/modify.
> -Ys-
> yhs@mimic.onesourcecorp.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Error with Session State?
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Fri, 15 Sep 2000, Sean McFadden wrote:
> I have a servlet that calls this sequence of methods:
>
> HttpSession session = request.getSession( true );
>
> // insert business logic here, and if certain conditions occur:
> session.invalidate();
> session = request.getSession( true );
> session.setAttribute( "foo", "bar" );
><SNIP>
> >From what I can make out, nothing is ever setting the serverSession in
> RequestImpl to null after StandardSession.invalidate() is called, so this
> method call does not produce a new serverSession as it should. Eyeballing the
> code sequence, it looks like the StandardSession knows that it's invalidated,
> and the StandardManager knows the session has been invalidated. But neither of
> these objects have a reference to the RequestImpl instance that "owns" the
> session, so they can't call setSession( null ). I haven't been able to quite
> make out how sessions get mapped to requests, or I would make submit a patch.
> It looks like this one will have to be taken care of by someone who knows a
> lot more about Tomcat internals than I do.
>
> Thanks,
> Sean
>
i reported this many moons ago and it was filed as a bug which was closed
by someone. its the cookie handling bug...i dont think anyone solved it
but you can work around it. look at my old bug report. its not a very
interesting bug obviously. treat cookies and sessions as write once
read many type states and you should be ok. dont try to delete/modify.
-Ys-
yhs@mimic.onesourcecorp.com
Error with Session State?
Posted by Sean McFadden <se...@wingateweb.com>.
I have a servlet that calls this sequence of methods:
HttpSession session = request.getSession( true );
// insert business logic here, and if certain conditions occur:
session.invalidate();
session = request.getSession( true );
session.setAttribute( "foo", "bar" );
Under Tomcat 3.1, this works great. Under Tomcat 3.2bX it is broken ( I tried
it using 3.2b2, 3.2b3, & 3.2b4 just to be sure ). On the call to
setAttribute(...), I get a java.lang.IllegalStateException: getAttribute:
Session already invalidated.
My second call to request.getSession( true ) gives me the same exact session
object, which has been invalidated. Under 3.1, I was getting a new session. I
believe that the following code snippet might have something to do with the
problem:
<code-snippet class="org.apache.tomcat.core.RequestImpl">
public HttpSession getSession(boolean create) {
if( serverSession!=null ) {
// if not null, it is validated by the session module
return serverSession;
}
// etc...
}
</code-snippet>
Re: Tomcat Logging
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Alex Chaffee wrote:
>
> On Tue, Aug 15, 2000 at 11:16:09AM -0700, cmanolache@yahoo.com wrote:
> > What about spliting "logging" from "debugging" ? It's clear there are
> > different requirements.
>
> Yes, but not *that* different.
>
> Logging messages are often used for debugging, and it's not always
> clear when a particular message is which.
>
> Here's a good quote I stole from the log4j docs:
>
> As Brian W. Kernigan and Rob Pike put it in their book The Practice of
> Programming
>
> As personal choice, we tend not to use debuggers beyond getting a
> stack trace or the value of a variable or two. One reason is that it
> is easy to get lost in details of complicated data structures and
> control flow; we find stepping through a program less productive
> than thinking harder and adding output statements and self-checking
> code at critical places. Clicking over statements takes longer than
> scanning the output of judiciously-placed displays. It takes less
> time to decide where to put print statements than to single-step to
> the critical section of code, even assuming we know where that
> is. More important, debugging statements stay with the program;
> debugging sessions are transient.
>
> If there were two different services (log vs. debug), then (a)
> developers would get confused as to which to use in the grey-zone
> cases, and (b) we may diverge and thus not benefit from all the common
> cases -> common code.
>
> Here's my vision of What Tomcat Needs from a logging package:
>
> (1) Configuration (via server.xml)
> (a) define files or non-file log targets by name
> (b) tell particular components, or sets of components, where to send their output, based both on message type and/or message source
> (c) tell particular components how verbose to be (this covers Costin's need for per-component debug level)
>
log4j can be configured using XML, we should be able to just specify its DTD
in server.xml with a namespace qualifier. Then make sure the tomcat XML
parser supports calling the log4j DOMConfigurator when it encouters that namespace.
log4j would support all the above configuration needs. Except it only has one
level of DEBUG, but we could get around that by subclassing its Category class
to add an integer debug level for Category.debug(). Then any place an XML
log4j element would be valid, a <debug> element would be valid.
You could get very specific and setup hundreds of different categories for various
tomcat componets. But I think we would want to limit it to the following:
Internal Tomcat log categories, each would support log levels of
EMERG, ALERT, CRIT, ERROR, WARN, NOTICE, INFO and DEBUG. We would subclass
log4j Category and provide an integer level to DEBUG.
Startup/Config
Http
Connector
Context
Jasper
Embedded
Security
Write a static class for each of the above, then in the code just
do something like the following when you want to log:
if( Startup.isDebug(int level) )
Startup.debug( String [, Throwable] );
or
Security.warn( String [, Throwable] );
...
The following are required by the Servlet API and would log at level INFO.
ServletContext.log // Required by Servlet API
GenericServlet.log // Required by Servlet API
Jasper for runtime JSP errors would use the Context log.
And we might want to put in place web server W3C style logging for Http
Connections.
We would want to be able to configure Context logging from ContextManager,
to VHost, to an individual Context. Where Context if not configured inherits
from VHost, and if VHost not configured it inherits from ContextManager.
We would want to keep some of the code in Logger that arbitrates which
Exceptions should generate a stack trace.
Comments?
How does the above line up with your ideas Alex?
There would be a fair amount of work to convert the current code base,
but some judicious use of perl -p -i -e could streamline the process.
log4j gives us a great deal of flexibility when logging. It can log
to unix syslog, NT event log, log to remote servers, and local files.
Plus there is even the ability to turn on/off debug logging remotely
w/o even having to restart tomcat or reload the config.
This would standardize logging and once implemented require very little
code maintenance.
Glenn
to touch
> (2) Component API
> (a) standard interface for telling components all of 1a,1b,and 1c
> (b) very simple API for a component to send a message and/or stacktrace to appropriate log (on the order of a mere 'log("foo");' just working)
>
If we move to log4j, its
> (3) Logging Package
> (a) set of classes for sending messages to wherever they need to go
> (b) must be high-performance -- if disabled, then take minimal or no CPU/memory
>
> Analysis of Existing Code:
>
> log4j would take care of 3 but not 1 or 2
>
> current tomcat.logging package takes care of 3, part of 2b
> (Logger.Helper)
>
> current server.xml takes care of some of 1, but in an inconsistent and
> not-fully-baked manner
>
> I'll send a proposal, including interface/class definitions, in a
> separate message, but I'd like some feedback on the above analysis
> before I proceed.
>
> > Even debugging - there are 2 kinds of debugging - abnormal situations that
> > happen at runtime and "traces" that you use to do println-debugging.
> >
> > I think it would be a good idea to use log(), debug() and trace() for
> > example.
>
> I agree that the utility of "WARN" is minimal, but I'd still like to
> see different "categories" (log4j's term) for
>
> * Error (important for users to always see these unless specifically
> disabled)
>
> * Information (the default Log type; this is where servlet log()
> messages would go)
>
> * Debug (with the additional caveat that each component has a separate
> variable determining which messages they shall send to this category)
>
> "trace" is a grey-zone category; I think "debug" covers this need, so
> "trace" is unnecessary and overcomplicates things.
>
> > For trace() I think the clasic old prinln will be enough (
> > since traceLevel should be 0 in normal use, enabled only to debug a
> > component ).
>
> Nope; what if the user is trying to debug an app that's hosted on an
> ISP, that he can't view the console of? ALL messages should be able
> to be directed to a file or elsewhere, configurably. Plus, this
> actually makes things simpler :-)
>
> - Alex
>
> --
> Alex Chaffee mailto:alex@jguru.com
> jGuru - Java News and FAQs http://www.jguru.com/alex/
> Creator of Gamelan http://www.gamelan.com/
> Founder of Purple Technology http://www.purpletech.com/
> Curator of Stinky Art Collective http://www.stinky.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Tomcat Logging
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
On Tue, Aug 15, 2000 at 11:16:09AM -0700, cmanolache@yahoo.com wrote:
> What about spliting "logging" from "debugging" ? It's clear there are
> different requirements.
Yes, but not *that* different.
Logging messages are often used for debugging, and it's not always
clear when a particular message is which.
Here's a good quote I stole from the log4j docs:
As Brian W. Kernigan and Rob Pike put it in their book The Practice of
Programming
As personal choice, we tend not to use debuggers beyond getting a
stack trace or the value of a variable or two. One reason is that it
is easy to get lost in details of complicated data structures and
control flow; we find stepping through a program less productive
than thinking harder and adding output statements and self-checking
code at critical places. Clicking over statements takes longer than
scanning the output of judiciously-placed displays. It takes less
time to decide where to put print statements than to single-step to
the critical section of code, even assuming we know where that
is. More important, debugging statements stay with the program;
debugging sessions are transient.
If there were two different services (log vs. debug), then (a)
developers would get confused as to which to use in the grey-zone
cases, and (b) we may diverge and thus not benefit from all the common
cases -> common code.
Here's my vision of What Tomcat Needs from a logging package:
(1) Configuration (via server.xml)
(a) define files or non-file log targets by name
(b) tell particular components, or sets of components, where to send their output, based both on message type and/or message source
(c) tell particular components how verbose to be (this covers Costin's need for per-component debug level)
(2) Component API
(a) standard interface for telling components all of 1a,1b,and 1c
(b) very simple API for a component to send a message and/or stacktrace to appropriate log (on the order of a mere 'log("foo");' just working)
(3) Logging Package
(a) set of classes for sending messages to wherever they need to go
(b) must be high-performance -- if disabled, then take minimal or no CPU/memory
Analysis of Existing Code:
log4j would take care of 3 but not 1 or 2
current tomcat.logging package takes care of 3, part of 2b
(Logger.Helper)
current server.xml takes care of some of 1, but in an inconsistent and
not-fully-baked manner
I'll send a proposal, including interface/class definitions, in a
separate message, but I'd like some feedback on the above analysis
before I proceed.
> Even debugging - there are 2 kinds of debugging - abnormal situations that
> happen at runtime and "traces" that you use to do println-debugging.
>
> I think it would be a good idea to use log(), debug() and trace() for
> example.
I agree that the utility of "WARN" is minimal, but I'd still like to
see different "categories" (log4j's term) for
* Error (important for users to always see these unless specifically
disabled)
* Information (the default Log type; this is where servlet log()
messages would go)
* Debug (with the additional caveat that each component has a separate
variable determining which messages they shall send to this category)
"trace" is a grey-zone category; I think "debug" covers this need, so
"trace" is unnecessary and overcomplicates things.
> For trace() I think the clasic old prinln will be enough (
> since traceLevel should be 0 in normal use, enabled only to debug a
> component ).
Nope; what if the user is trying to debug an app that's hosted on an
ISP, that he can't view the console of? ALL messages should be able
to be directed to a file or elsewhere, configurably. Plus, this
actually makes things simpler :-)
- Alex
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Tomcat Logging
Posted by Costin Manolache <cm...@yahoo.com>.
> Yes, it's important to keep the ability to maintain multiple log
> files. One target architecture for Tomcat is an ISP hosting hundreds
> of different webapps for different clients; with multiple log files
> (one per webapp) the admin can maintain security (so people can't read
> each other's logs).
There are 2 ways to do that:
- either provide a separate log per webapp ( or group of webapps,
i.e. customer).
- or keep all logs in one place and provide an API ( or an alternate
method ) to access the logs.
The most convenient is the first, and if the log is written in the
workdir for the webapp the user can use a simple servlet to get
it ( it'll be tomcat specific ).
The only problem is scalability - an ISP has 100+ customers and
keeping 100+ open file descriptors is not a solution. Keeping a
pool will also have an impact.
I'm not saying this is a bad solution - but I don't think it scales.
It is perfect for small sites.
The second is to store all logs in a single repository and either
provide an API ( where checks for user id is done)
or do a post-processing.
Post processing means every day ( or hour ) the common log filed
is processed and individual log files are generated.
That also means a binary format can be used ( i.e. no formating
or expensive processing ) and it also means an external process
( maybe offline, separate machine ) can do the job without
affecting the production server.
This config has the minimal impact on the server performance.
Even today it is possible to switch the logger ( extending it for
example ), but I would love to see the the second solution.
( BTW, don't even try to store the logs in a database - it's
too slow.)
> I'm wary of the NDC approach; as you said, since Tomcat uses thread
> pooling, it would require activity before and after each request.
> This would surely have some impact on performance (especially if it
> requires allocating new objects -- a main part of the performance
> tuning Costin's doing is minimizing GC).
As long as the logger is configurable I think we are ok.
Keeping the memory and CPU usage low requires a lot
of discipline and effort - but we are talking about a small
server with a clear functionality, not a GUI or complex
application.
> 1. configuration (though I can imagine with a bit of cleverness we
> could delegate most or all of the log config out of server.xml and
> into log4j's config file)
Having the logger as a "standalone" bean ( i.e. no deps on tomcat) is
very important.
Having external configuration ( i.e. bean setters) proved to be
very good for tomcat, and I think it's a pattern we want to keep.
How those setters are called ( server.xml or EmbededFooApp)
is not so important.
Tomcat will have deps on logger, and will have to adapt to
it's configuration anyway.
> 2. standardizing the way a component knows which category/target to
> write to. This could be as simple as a string property (instance
> variable) with log4j category, or maybe an interface, something like
Or we can just keep it simple and trust the developers to follow
some patterns. If it's really simple to use ( like one line to
get the logger, one line to use it) we'll have more chance to have
the logger used and re-used.
LogAware is fine, but I think having a simple
Logger {
static Logger getLogger( String category, etc)
log( .... )
}
will be enough.
> 3. regulating "debug" level (so a component won't even execute the
> code that builds the debug log strings -- which may involve some heavy
> lifting -- this simply can't be handled by library code in Java)
For debug ( and we want to have as much debug() as possible )
I think we should use a special rule,
if( debug > level ) debug()
( maybe with static debug )
Smart compilers will remove this - and I don't think there is anything
equivalent.
Costin
Re: Tomcat Logging
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alex Chaffee wrote:
> The per-context or per-component category idea seems more sound.
> Again, it would only solve the output side of things (#3 on my
> original list); we'd still have to write Tomcat code to handle
>
I agree with the thinking that per-context (or more generally, per-container) is the
best way to organize logging output, for the reasons that you described earlier.
Alex, have you looked at how loggers are configured in Catalina (i.e. the
"jakarta-tomcat-4.0" module) yet? They deal with your #3 issue, because they are
attached to a container -- which can be any of the entire server, a particular virtual
host, or a particular web-app -- and you can override the logger assigned to a
lower-level container if you want to, as illustrated in the default server.xml file.
The current Catalina design addresses your other issues as follows:
>
> 1. configuration (though I can imagine with a bit of cleverness we
> could delegate most or all of the log config out of server.xml and
> into log4j's config file)
>
Configuration of Catalina loggers follows the usual pattern for parsing
"conf/server.xml", where it matches a particular element -- in this case a <Logger> --
nested within a container element (<Engine>, <Host>, or <Context>). You use the
"className" attribute to choose which Logger implementation class to load (see below
for more details), and then does the usual Java reflection to match up the rest of the
attributes with JavaBeans property setters on the Logger implementation object. That
way, different logger implementations need not have the same configuration properties.
All Logger implementations must implement org.apache.catalina.Logger, which has log()
calls that cover the usual patterns of things you want (including the optional ability
to declare a severity level and have your logger implementation do filtering). The
current set of available logger implementations (in package
org.apache.catalina.loggers) includes:
* Log to system output
* Log to system error
* Log to a configurable filename pattern in
a configurable directory, with automatic
switchover to new log files at midnight
(the date is in the filename).
>
> 2. standardizing the way a component knows which category/target to
> write to. This could be as simple as a string property (instance
> variable) with log4j category, or maybe an interface, something like
>
Essentially every internal Catalina component is attached to a Container of some sort,
so it's real easy:
getContainer().getLogger().log("your message goes here");
If your component is connected to a Context (say, it's the session manager), and you
have not assigned a specific Logger to this web app, the getLogger() method
automatically walks up the container hierarchy until it finds an assigned Logger.
Thus, you can change the configuration file to log all the webapps for a virtual host
together, if you want, without modifying any code.
For components that are not internal to Catalina, (such as the Jasper servlet), I would
suggest that we use the ServletContext.log() mechanism -- otherwise, it would be
introducing dependencies between Catalina and Jasper that hinder portability. Of
course, those issues can be addressed with adapter classes that are used when Catalina
and Jasper really are configured together if we want to.
>
> interface LogAware {
> void setLogTarget(String category);
> }
>
> or, better:
>
> interface LogAware {
> void setLogger(Logger l);
> }
>
> interface Logger {
> void setCategory(String category); // for writing directly to a log4j category
> void setMaster(Logger logger); // for delegating to a parent
> void log(String msg);
> // etc.
> }
>
> and then appropriate helper and impl classes, and implementing it in
> all components.)
>
This is addressed differently in the current Catalina implemenation, as described
above.
>
> 3. regulating "debug" level (so a component won't even execute the
> code that builds the debug log strings -- which may involve some heavy
> lifting -- this simply can't be handled by library code in Java)
>
The org.apache.catalina.Logger interface includes the concept of a verbosity level
(with standard constants for the usual suspects: FATAL, ERROR, WARNING, INFORMATION,
and DEBUG). If you call a log() method that does not have a verbosity argument, the
message (or message and exception) are logged unconditionally. Otherwise, they are
filtered based on the verbosity level you have configured for the logger.
To get around performance issues of creating log messages that I'm going to throw away,
most of the existing Catalina components have a "debug" property set to an integer
value (default = 0). Then, you'll see code like this:
if (debug >= 1)
logger.log("some debugging message goes here")
so that you don't have to compute the message string, which might include string
concatenations etc., unless you are really going to use it. But you can still do
logger-level filtering as well if you want to.
>
> and probably some more things I've forgotten :-)
>
On a long-running server, I've found the "automatic rollover to new files each day"
feature to be incredibly handy, and have built it into all of my server applications
for years. I would suggest that we keep this concept no matter what ultimate logging
approach is chosen.
>
> - Alex
>
Craig
Re: Tomcat Logging
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
Ceki -
Thanks for the thorough reply.
Yes, it's important to keep the ability to maintain multiple log
files. One target architecture for Tomcat is an ISP hosting hundreds
of different webapps for different clients; with multiple log files
(one per webapp) the admin can maintain security (so people can't read
each other's logs).
I'm wary of the NDC approach; as you said, since Tomcat uses thread
pooling, it would require activity before and after each request.
This would surely have some impact on performance (especially if it
requires allocating new objects -- a main part of the performance
tuning Costin's doing is minimizing GC).
The per-context or per-component category idea seems more sound.
Again, it would only solve the output side of things (#3 on my
original list); we'd still have to write Tomcat code to handle
1. configuration (though I can imagine with a bit of cleverness we
could delegate most or all of the log config out of server.xml and
into log4j's config file)
2. standardizing the way a component knows which category/target to
write to. This could be as simple as a string property (instance
variable) with log4j category, or maybe an interface, something like
interface LogAware {
void setLogTarget(String category);
}
or, better:
interface LogAware {
void setLogger(Logger l);
}
interface Logger {
void setCategory(String category); // for writing directly to a log4j category
void setMaster(Logger logger); // for delegating to a parent
void log(String msg);
// etc.
}
and then appropriate helper and impl classes, and implementing it in
all components.)
3. regulating "debug" level (so a component won't even execute the
code that builds the debug log strings -- which may involve some heavy
lifting -- this simply can't be handled by library code in Java)
and probably some more things I've forgotten :-)
- Alex
P.S. This is fun! It's really helping me flesh out my understanding
of the issues. Hopefully, even if we don't use log4j with Tomcat, we
can each help the other's product get stronger...
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Tomcat Logging
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
Hi Ceki -
I haven't quite finished my proposal, so hopefully when I do you'll
see what I mean, but briefly...
As I understand from perusing the docs, in log4j client code specifies
the target category, which is then directed by log4j to the right
place. But in Tomcat, we have common code running in many different
contexts/webapps, and each may have its own log targets, according to
dynamic server.xml configuration. So we still need a higher level of
specification of the category.
> Here, I am assuming that the words category and component are
> equivalent. This is the case if components have their own category.
Not so; a component is an *instance* of a class, running in a certain
webapp. Is log4j smart enough to note the "this" pointer of the
calling code? I can't see how it could be.
- A
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Tomcat Logging
Posted by Gulcu Ceki <cg...@zurich.ibm.com>.
Hi Alex,
Alex Chaffee wrote:
> Here's my vision of What Tomcat Needs from a logging package:
>
> (1) Configuration (via server.xml)
> (a) define files or non-file log targets by name
>
> (b) tell particular components, or sets of components, where to send
> their output, based both on message type and/or message source
>
> (c) tell particular components how verbose to be (this covers
> Costin's need for per-component debug level)
>
> (2) Component API
> (a) standard interface for telling components all of 1a,1b,and 1c
>
> (b) very simple API for a component to send a message and/or
> stacktrace to appropriate log (on the order of a mere 'log("foo");'
> just working)
>
> (3) Logging Package
> (a) set of classes for sending messages to wherever they need to go
>
> (b) must be high-performance -- if disabled, then take minimal or no
> CPU/memory
>
> Analysis of Existing Code:
>
> log4j would take care of 3 but not 1 or 2
Why is that? In log4j, you can
1a) Define log targets by name,
1b) Tell particular categories or category sets where to send their
output based on their category or message priority,
1c) Tell particular component how verbose to be,
Here, I am assuming that the words category and component are
equivalent. This is the case if components have their own category.
2a) Definitely. Log4j has a very general interface for configuring
components. You can configure all of log4j environment with a
properties file or an XML file without writing a single line of
code (true for log4j 0.8.5). In previous log4j versions you need a
single line of code to invoke a configurator.
2b) This is usually true for most logging APIs including log4j.
I would be very interested to know why you think log4j does not
fulfill conditions 1 and 2. Regards, Ceki
Re: Catalina/Tomcat performance/functionality
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Roy Wilson wrote:
>
> Since I am not (yet) a Tomcat/Catalina developer, there may not be
> much reason to take these performance related questions too seriously,
> if at all. I hope, however, they might prove useful.
I believe you didn't really understand what we mean by performance...
> In the Catalina proposal, the following comments were made concerning
> performance.
>
> "No formal benchmarks have been published by the Tomcat development
> team describing the performance of Tomcat 3.x or Catalina."
Yes, and that's true. I know that some of us ran some performance tests
stressing the different web servers and different http stacks, but we
don't yet have a formal performance report.
> QUESTION 1: What is meant by "formal" benchmark? See below on data
> collected (but not on Tomcat) using ApacheBench: is this a formal
> benchmark, an informal benchmark, or neither?
What you did is not even a benchmark :) What you measured is the latency
time between codeflux.com and jakarta.apache.org, over the INTERNET...
Just a simple example: if I try to run ApacheBench on my machine using
as URL my host name (http://www.betaversion.org/) I get these results:
Server Software:
Apache/1.3.12
Server Hostname: www.betaversion.org
Server Port: 80
Document Path: /
Document Length: 1358 bytes
Concurrency Level: 1
Time taken for tests: 0.384 seconds
Complete requests: 10
Failed requests: 0
Total transferred: 17810 bytes
HTML transferred: 13580 bytes
Requests per second: 26.04
Transfer rate: 46.38 kb/s received
Running the _same_ test from the codeflux gateway I get:
Server Software: Apache/1.3.12
Server Hostname: www.betaversion.org
Server Port: 80
Document Path: /
Document Length: 1358 bytes
Concurrency Level: 1
Time taken for tests: 6.470 seconds
Complete requests: 10
Failed requests: 0
Total transferred: 17810 bytes
HTML transferred: 13580 bytes
Requests per second: 1.55
Transfer rate: 2.75 kb/s received
WHHHATTTTT??? Am I nuts? from 26 requests per seconds to 1.55? What's
wrong with my site? Nothing it's my test methodology. In the second case
I am measuring network latency.
> "(In addition, I would take any benchmark that purports to predict how
> *your* application will perform on a particular server with a very
> large grain of salt :-)."
Well, as far as I can see, our benchmarks are more accurate than yours.
> I agree: this is a big can of worms (to be opened later, if ever).
No, it's not... Performance testin (as Mike Pogue from IBM docet) is a
very intricate matter, but certainly, in some situations, can be
resolved. Of course we cannot say which server or servlet engine is
faster, but we can make real-world examples and give a test methodology
that in your environment can be followed and used by you to determine
what's best for your needs.
> "However, simple tests with tools like ApacheBench and Microsoft's
> stress test indicate that Catalina is faster than Tomcat on serving
> static resources (substantially faster if caching is enabled,
> basically on par with Apache itself), and within a few percentage
> points on serving "Hello, World" type servlets and JSP pages."
>
> It would be nice to see the results of at least the ApacheBench test
> since ApacheBench is potentially available to all developers via the
> ApacheBench Gateway at codeflux.com.
CodeFlux is (as the name says) a gateway that merely measures the
network latency times between their host and whatever URL you enter...
It's not a web-server benchmark, it's a network benchmark.
> [... skipped digression over codeflux tests...]
> QUESTION 2: Using the criteria given above, does this mean that the
> Apache web server is not a "good" web server? (I understand that, per
> the goals of the ASF, functionality should dominate performance).
Given that the test metodology is wrong this question is not pertinent.
Try to re run YOUR test with this URL:
<http://codeflux.com/images/tell.gif>
Apache 1.3.4 processes approximately 36 requests per seconds... Whoha!
> QUESTION 3: Does Catalina have any performance REQUIREMENTS? On page
> 12 of "Java Platform Performance", Steve Wilson and Jeff Kesselman of
> Sun suggest the need to "reach a consensus about the performance
> requirements for your system. If you don't, how will you know when
> your product is fast enough". If such advice doesn't apply here, why
> not?
I don't agree with Wilson and Kesselman on that. Our requirements (after
of course our requirements of being compliant to the spec and bug-free)
are to be "faster". And the codebase is clean enough to see where our
performance weak points are. We know how current VMs are working, what
is an overhead and what is not. I believe we can achieve very good
results only looking at our code...
> [... skipped descriptions of what's in the files...]
>
> QUESTION 4: will Catalina traffic look more like URL1 or URL2 or some
> mix of the two or some other mix.
None of the above. You're measuring the network.
> QUESTION 5: what will be the consequences of answering question 4 for
> user-level performance?
With your test-case, just buy more bandwidth, and sit your host on the
AXXS network (http://www.axxs.net/)
> "Only modest efforts to tune Catalina have taken place to date
> (compared to the substantial -- and successful -- tuning efforts
> expended between Tomcat 3.1 and 3.2), so it can be assumed that there
> is still significant room for improvement through the usual techniques
> of isolating hot spots and optimizing them."
>
> While I agree that this is the usual technique, there are those who
> suggest it may not be enough. Some suggest that performance is
> functionality: if it takes 10 minutes to login to a system, it isn't
> functional in an meaningful sense (I am not predicting that such an
> event would occur, only noting that it did occur elsewhere). In the
> horror story I mentioned in an earlier post, there were no
> REQUIREMENTS up front. It was assumed that intelligent design, coding,
> tuning. and a bigger pipe/hammer/etc. would be enough. They weren't.
> Sorry for the preachiness.: please educate me.
As I told before, maybe we don't have _requirements_ bu we know what's
going on and how to improve our performances. We just need programmers
time to go in and optimize.
> If there is a version of Tomcat or Catalina that is up that can be
> accessed using the codeflux.com ApacheBench Gateway, I am happy to
> volunteer for some additional monkey-test work :-) like that done in
> producing the data shown in the attachment.
Don't worry. Using codeflux is completely useless in terms of
benchmarking the internals of any web server.
Pier
Catalina/Tomcat performance/functionality
Posted by Roy Wilson <de...@bellatlantic.net>.
Since I am not (yet) a Tomcat/Catalina developer, there may not be much
reason to take these performance related questions too seriously, if at
all. I hope, however, they might prove useful.
In the Catalina proposal, the following comments were made concerning
performance.
"No formal benchmarks have been published by the Tomcat development team
describing the performance of Tomcat 3.x or Catalina."
QUESTION 1: What is meant by "formal" benchmark? See below on data
collected (but not on Tomcat) using ApacheBench: is this a formal
benchmark, an informal benchmark, or neither?
"(In addition, I would take any benchmark that purports to predict how
*your* application will perform on a particular server with a very large
grain of salt :-)."
I agree: this is a big can of worms (to be opened later, if ever).
"However, simple tests with tools like ApacheBench and Microsoft's stress
test indicate that Catalina is faster than Tomcat on serving static
resources (substantially faster if caching is enabled, basically on par
with Apache itself), and within a few percentage points on serving
"Hello, World" type servlets and JSP pages."
It would be nice to see the results of at least the ApacheBench test
since ApacheBench is potentially available to all developers via the
ApacheBench Gateway at codeflux.com.
I ran ab gateway tool using jakarta.apache.org as the server hostname and
Apache/1.3.13-dev as the server software. According to the ab gateway
documentation, "a good web server can process a static HTML page in under
10 ms, ..., with overall turnaround time consistently well under 100 ms".
As a benchmarking exercise, I used the following two http addresses. I
believe these are static pages, but I didn't bother to try to determine
this one way or the other.
(1)/tomcat/index.html
(2)/catalina-proposal.html?rev1.1 (URL is no longer current)
The first URL produced an average per request response time of between
250 and 260 ms, even with a (request) concurrency level of 5.
QUESTION 2: Using the criteria given above, does this mean that the
Apache web server is not a "good" web server? (I understand that, per the
goals of the ASF, functionality should dominate performance).
QUESTION 3: Does Catalina have any performance REQUIREMENTS? On page 12
of "Java Platform Performance", Steve Wilson and Jeff Kesselman of Sun
suggest the need to "reach a consensus about the performance requirements
for your system. If you don't, how will you know when your product is
fast enough". If such advice doesn't apply here, why not?
The second URL produced an average response time between 923 and 3440 ms.
Increased request concurrency leads, in the first case, to better
throughput, presumably because of caching of system resources. In the
second case, increased request concurrency actually leads to a decrease
in throughput. One or more underlying hardware/software/data resources
are being saturated by this request. I've attached a StarOffice5.2 Calc
(plus an Excel 95) spreadsheet with the details.
QUESTION 4: will Catalina traffic look more like URL1 or URL2 or some mix
of the two or some other mix.
QUESTION 5: what will be the consequences of answering question 4 for
user-level performance?
"Only modest efforts to tune Catalina have taken place to date (compared
to the substantial -- and successful -- tuning efforts expended between
Tomcat 3.1 and 3.2), so it can be assumed that there is still significant
room for improvement through the usual techniques of isolating hot spots
and optimizing them."
While I agree that this is the usual technique, there are those who
suggest it may not be enough. Some suggest that performance is
functionality: if it takes 10 minutes to login to a system, it isn't
functional in an meaningful sense (I am not predicting that such an event
would occur, only noting that it did occur elsewhere). In the horror
story I mentioned in an earlier post, there were no REQUIREMENTS up
front. It was assumed that intelligent design, coding, tuning. and a
bigger pipe/hammer/etc. would be enough. They weren't. Sorry for the
preachiness.: please educate me.
If there is a version of Tomcat or Catalina that is up that can be
accessed using the codeflux.com ApacheBench Gateway, I am happy to
volunteer for some additional monkey-test work :-) like that done in
producing the data shown in the attachment.
Roy
--
Roy Wilson
E-mail: designrw@bellatlantic.net
Re: Tomcat Logging
Posted by Sven Reimers <re...@tu-harburg.de>.
Hi,
I did not know where ot pick up th thread so I just start here.
I am using Tomcat and using log4j for logging in some of my projects. So
may be I just may shed some light on terms flying around here:
1. categories: are just what they are named - they are used in
hierarchical manner
EXAMPLE
org.apache.tomcat.subpackageone
org.apache.tomcat.subpackageone.classone
both would be different categories but could send their logging
information to
the same appender (see below). There is a feature called additivity
that would allow
logging infos sent to classone also be logged with subpackageone.
2. appenders: they are the ones doing the work . they receive the
logging information and
process it in a way implemented by the appender. There are already
appenders for patternbased
logging, socketbased, nt /syslog .... Each category may have
multiple appenders
I should think that should for Tomcat. If you want more (other)
priorites, you may send
a request to log4j mailing-list (I could do that) and discuss it with
Ceki. There is currently
some changing underway that includes support for subclassing categories
new implementation
of the hierarchy management and with this possible changes to priority
code/design.
I hope that this helps a bit.
Just my 0.02$
Sven
cmanolache@yahoo.com wrote:
>
> What about spliting "logging" from "debugging" ? It's clear there are
> different requirements.
>
> Even debugging - there are 2 kinds of debugging - abnormal situations that
> happen at runtime and "traces" that you use to do println-debugging.
>
> I think it would be a good idea to use log(), debug() and trace() for
> example. For trace() I think the clasic old prinln will be enough (
> since traceLevel should be 0 in normal use, enabled only to debug a
> component ).
>
> Costin
>
> On Tue, 15 Aug 2000, Alex Chaffee wrote:
>
> > > > The W3C format is for HTTP access logs, not debugging/message logs.
> >
> > > actually you can modify the header to be any message you want.
> >
> > That may be so but it's still not meant for or appropriate for
> > debug-style log messages.
> >
> > * Some requests produce more than one message; this would produce
> > redundant entries
> >
> > * Some messages happen outside the context of a request, either in the
> > background, or in library code that does not and should not know the
> > details of the request to pass them on to the logger.
> >
> > --
> > Alex Chaffee mailto:alex@jguru.com
> > jGuru - Java News and FAQs http://www.jguru.com/alex/
> > Creator of Gamelan http://www.gamelan.com/
> > Founder of Purple Technology http://www.purpletech.com/
> > Curator of Stinky Art Collective http://www.stinky.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat Logging
Posted by cm...@yahoo.com.
What about spliting "logging" from "debugging" ? It's clear there are
different requirements.
Even debugging - there are 2 kinds of debugging - abnormal situations that
happen at runtime and "traces" that you use to do println-debugging.
I think it would be a good idea to use log(), debug() and trace() for
example. For trace() I think the clasic old prinln will be enough (
since traceLevel should be 0 in normal use, enabled only to debug a
component ).
Costin
On Tue, 15 Aug 2000, Alex Chaffee wrote:
> > > The W3C format is for HTTP access logs, not debugging/message logs.
>
> > actually you can modify the header to be any message you want.
>
> That may be so but it's still not meant for or appropriate for
> debug-style log messages.
>
> * Some requests produce more than one message; this would produce
> redundant entries
>
> * Some messages happen outside the context of a request, either in the
> background, or in library code that does not and should not know the
> details of the request to pass them on to the logger.
>
> --
> Alex Chaffee mailto:alex@jguru.com
> jGuru - Java News and FAQs http://www.jguru.com/alex/
> Creator of Gamelan http://www.gamelan.com/
> Founder of Purple Technology http://www.purpletech.com/
> Curator of Stinky Art Collective http://www.stinky.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Tomcat Logging
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
> > The W3C format is for HTTP access logs, not debugging/message logs.
> actually you can modify the header to be any message you want.
That may be so but it's still not meant for or appropriate for
debug-style log messages.
* Some requests produce more than one message; this would produce
redundant entries
* Some messages happen outside the context of a request, either in the
background, or in library code that does not and should not know the
details of the request to pass them on to the logger.
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Tomcat Logging
Posted by Craig McClanahan <Cr...@eng.sun.com>.
Alex Chaffee wrote:
> >
> > logging is rather simple. i'd like tomcat to use the W3C extended logfile
> > format though..its extensible to a XML based logfile in the future...does
> > log4j do this ? i had to write my own ELF logging code patch for tomcat...
> > http://www.w3.org/TR/WD-logfile.html
>
> The W3C format is for HTTP access logs, not debugging/message logs. I
> believe Tomcat already uses a standard format for access logs, but I
> don't use it so I may be wrong. In any case you can't use the W3C
> format for arbitrary messages.
>
Tomcat 3.x does not produce web server style access logs itself (unless someone
added a RequestInterceptor to do this when I wasn't looking -- it would be very
easy). It relies on the web server to do the access logging when used behind
one.
Catalina has a Valve implementation of access logging for stand-alone use that
is a pretty substantial subset of the configurable logfile format that Apache
lets you do.
>
> --
> Alex Chaffee mailto:alex@jguru.com
> jGuru - Java News and FAQs http://www.jguru.com/alex/
> Creator of Gamelan http://www.gamelan.com/
> Founder of Purple Technology http://www.purpletech.com/
> Curator of Stinky Art Collective http://www.stinky.com/
>
Craig McClanahan
Re: Tomcat Logging
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Tue, 15 Aug 2000, Alex Chaffee wrote:
> >
> > logging is rather simple. i'd like tomcat to use the W3C extended logfile
> > format though..its extensible to a XML based logfile in the future...does
> > log4j do this ? i had to write my own ELF logging code patch for tomcat...
> > http://www.w3.org/TR/WD-logfile.html
>
> The W3C format is for HTTP access logs, not debugging/message logs. I
> believe Tomcat already uses a standard format for access logs, but I
> don't use it so I may be wrong. In any case you can't use the W3C
> format for arbitrary messages.
>
> --
> Alex Chaffee mailto:alex@jguru.com
actually you can modify the header to be any message you want.
For example :
#Version: 1.0
#Date: 12 jan 1996 00:00:00
#Remark: W3C Extended Log File format
#Remark: http://www.w3.org.TR/WD-logfile.html
#Fields: date time c-ip cs-method cs-uri s-comment
#Remark: Startup sequence...
2000-08-15 12:43:38 10.0.0.99 GET /servlet/msv User abc logged in.
modifying the fields parameter changes the messages. you can combine
different fields parameters for different results. Fields can be changed
dynamically in the middle of the file or even be XML tags wrapped around
data.
e.g.
#Fields: s-comment date s-comment time s-comment
<MY_XML_TAG= 2000-08-15 ><MORE_XML= 12:43:38 ><!--arbitrary comment-->
You get the idea...
-Ys-
yhs@mimic.onesourcecorp.com
Re: Tomcat Logging
Posted by cm...@yahoo.com.
>
> The W3C format is for HTTP access logs, not debugging/message logs. I
> believe Tomcat already uses a standard format for access logs, but I
> don't use it so I may be wrong. In any case you can't use the W3C
> format for arbitrary messages.
Tomcat standalone have no access log ( it has one if embeded in J2EE
). It's easy to add one - but since nobody asked for I guess it's not a
high priority ?
Costin
Re: Tomcat Logging
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
>
> logging is rather simple. i'd like tomcat to use the W3C extended logfile
> format though..its extensible to a XML based logfile in the future...does
> log4j do this ? i had to write my own ELF logging code patch for tomcat...
> http://www.w3.org/TR/WD-logfile.html
The W3C format is for HTTP access logs, not debugging/message logs. I
believe Tomcat already uses a standard format for access logs, but I
don't use it so I may be wrong. In any case you can't use the W3C
format for arbitrary messages.
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Tomcat Logging
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
I worked a bit on logging, but I've put it on the back burner for a while.
log4j is nice, but there may be issues with the license (they use IBM
not Apache)
Also, there's some work to be done to the Tomcat code even if we move
to a log4j backend. We'd like each component in each context to be
able to change its log parameters (what category name, what
destination, what debug level worth of messages get shown) based on
server.xml entries. Right now it sorta works but isn't really fully
conceived.
I'd be happy to start a thread on discussion of logging design.
- Alex
On Mon, Aug 14, 2000 at 12:35:09PM -0400, yhs@mimic.onesourcecorp.com wrote:
>
>
> On Sun, 13 Aug 2000, Glenn Nielsen wrote:
>
> > This may have been discussed before, but I don't recall seeing it,
> > or it may have been discussed before I started reading this list.
> >
> > I was looking at
> >
> > http://www.log4j.org/
> >
> > a logging API for Java written by IBM and released under IBM's open source
> > license.
> >
> > Has any consideration been given to using this for Tomcat logging?
> >
> > There has been some discussion about making improvements to Tomcats
> > logging. Perhaps log4j could be implemented rather than spend alot
> > of time on our own code.
> >
> > I know IBM contributes a great deal to the ASF, such as xerces.
> >
> > Regards,
> >
> > Glenn
> >
>
> logging is rather simple. i'd like tomcat to use the W3C extended logfile
> format though..its extensible to a XML based logfile in the future...does
> log4j do this ? i had to write my own ELF logging code patch for tomcat...
> http://www.w3.org/TR/WD-logfile.html
> -Ys-
> yhs@mimic.onesourcecorp.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Tomcat Logging
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Sun, 13 Aug 2000, Glenn Nielsen wrote:
> This may have been discussed before, but I don't recall seeing it,
> or it may have been discussed before I started reading this list.
>
> I was looking at
>
> http://www.log4j.org/
>
> a logging API for Java written by IBM and released under IBM's open source
> license.
>
> Has any consideration been given to using this for Tomcat logging?
>
> There has been some discussion about making improvements to Tomcats
> logging. Perhaps log4j could be implemented rather than spend alot
> of time on our own code.
>
> I know IBM contributes a great deal to the ASF, such as xerces.
>
> Regards,
>
> Glenn
>
logging is rather simple. i'd like tomcat to use the W3C extended logfile
format though..its extensible to a XML based logfile in the future...does
log4j do this ? i had to write my own ELF logging code patch for tomcat...
http://www.w3.org/TR/WD-logfile.html
-Ys-
yhs@mimic.onesourcecorp.com