You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Bill Schneider <bs...@vecna.com> on 2003/01/17 19:30:32 UTC

log4j writing to ServletContext.log()

To get around the problems I was having with log4j in a clustered
environment (multiple processes on one filesystem), I wrote a new appender
that writes to the servlet log as if you called servletContext.log(...).
Has anyone thought of doing this before?  Hadn't seen much on the lists
about it.  I can submit the code if anyone is interested.

The catch is, somehow you have to initialize the appender with the
ServletContext objcet.  I arrived at a method "static public void
setServletContext".  Since we're already initializing log4j from a
ServletContextListener, it's fairly trivial to call
ServletLogAppender.setServletContext(...) from the context listener
immediately after initializing log4j.

[[Speaking of which, it might be nice to have a standard log4j context
loader that you can just dump into web.xml and point at a properties file.
We've implemented one trivially, but I'm sure lots of other folks already
rolled their own too.]]

Benefits: only one log file to worry about rolling and archiving; log4j
events go right alongside app server events; and the app server should take
responsibility for synchronizing writes or separating logs by process.

Problems: Assumes a one-to-one mapping between classloaders and servlet
contexts.  It won't work inside EJBs, since EJBs are in a different
classloader.

The JMSAppender is the real long-term solution, although that requires
someone to be listening for and recording the messages.  But a
ServletLogAppender will work nicely in a cluster of "pure" (non-EJB-ified)
webapps.

-- Bill


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: log4j writing to ServletContext.log()

Posted by Jacob Kjome <ho...@visi.com>.
Hello Bill,

Sounds interesting.  Can you post it along with instructions on use?
I'd like to try it.

Jake

Friday, January 17, 2003, 12:30:32 PM, you wrote:

BS> To get around the problems I was having with log4j in a clustered
BS> environment (multiple processes on one filesystem), I wrote a new appender
BS> that writes to the servlet log as if you called servletContext.log(...).
BS> Has anyone thought of doing this before?  Hadn't seen much on the lists
BS> about it.  I can submit the code if anyone is interested.

BS> The catch is, somehow you have to initialize the appender with the
BS> ServletContext objcet.  I arrived at a method "static public void
BS> setServletContext".  Since we're already initializing log4j from a
BS> ServletContextListener, it's fairly trivial to call
BS> ServletLogAppender.setServletContext(...) from the context listener
BS> immediately after initializing log4j.

BS> [[Speaking of which, it might be nice to have a standard log4j context
BS> loader that you can just dump into web.xml and point at a properties file.
BS> We've implemented one trivially, but I'm sure lots of other folks already
BS> rolled their own too.]]

BS> Benefits: only one log file to worry about rolling and archiving; log4j
BS> events go right alongside app server events; and the app server should take
BS> responsibility for synchronizing writes or separating logs by process.

BS> Problems: Assumes a one-to-one mapping between classloaders and servlet
BS> contexts.  It won't work inside EJBs, since EJBs are in a different
BS> classloader.

BS> The JMSAppender is the real long-term solution, although that requires
BS> someone to be listening for and recording the messages.  But a
BS> ServletLogAppender will work nicely in a cluster of "pure" (non-EJB-ified)
BS> webapps.

BS> -- Bill


BS> --
BS> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
BS> For additional commands, e-mail: <ma...@jakarta.apache.org>



-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>