Quick question on "the scope of Log4j's configuration settings"

[Lutz Michael <mi...@siemens.com>]

Thanks in advance for any feedback.

My organization has a non-negotiable requirement to support many customers
on a given machine.  The J2EE servlet standard has rules specifying how each
web application in a servlet container owns its own class loader.  Thus, in
the same JVM process space, we are able to support multiple customers
running multiple versions of our code.

The question deals with Log4j's ability to be configured differently for
such customers, given the fact that they may be running in the same JVM
process space, but under different web applications.

So the question is - when Log4j is configured, what is the scope of the
configuration settings?  I've looked through the documentation (which is
excellent) and couldn't find this answer (maybe the answer is implied and I
just didn't get it).  Is the scope the entire JVM process space, thus
disallowing our scenario?  ... or following Ceki's servlet-based
configuration pattern (http://jakarta.apache.org/log4j/docs/manual.html), in
a servlet world (and if we include the Log4j jar's in each Web application),
can we isolate the effect of configuring Log4j to distinct Web applications
even though they run in the same JVM space?

I'm thinking the question really comes down to - (a) how does Log4j
internally maintain config settings (statics?), and (b) what is the effect
from a scope perspective of this approach - e.g. can we isolate down to the
web application level inside a single JVM space and servlet container.

This question is very important to my organization, thanks for your time.

Mike

-------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions 
Health Services Corporation and are intended only for the addressee(s).  
The information contained herein may include trade secrets or privileged or 
otherwise confidential information.  Unauthorized review, forwarding, printing, 
copying, distributing, or using such information is strictly prohibited and may 
be unlawful.  If you received this message in error, or have reason to believe 
you are not authorized to receive it, please promptly delete this message and 
notify the sender by e-mail with a copy to CSOffice@smed.com.  Thank you

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

Re: Quick question on "the scope of Log4j's configuration settings"

[Jacob Kjome <ho...@visi.com>]

Hello Lutz,

Putting log4j.jar inside WEB-INF/lib of each webapp solves this issue
immediately.  The other comments about repository selectors are true
and valid, but, if you want to simplify things, simply putting a
separate copy of log4j.jar in the WEB-INF/lib of every webapp you
deploy will provide for a separate logger configuration environment
per/webapp.

Now, if you want all apps to share log4j, you can use something like
the ContextClassLoaderSelector which is included in the CVS for
Log4j-1.3.  When you start up your app, make your configuration
servlet or servlet context listener call
ContextClassLoaderSelector.doIdempotentInitialization() before you
call any configure() method.

Now your app will be using its own logger repository keyed upon the
current webapp's classloader.  This provides the same sort of separate
logger configuration envionment that the first case (above) provides for.

Jake


Friday, January 10, 2003, 8:54:06 AM, you wrote:



LM> Thanks in advance for any feedback.

LM> My organization has a non-negotiable requirement to support many customers
LM> on a given machine.  The J2EE servlet standard has rules specifying how each
LM> web application in a servlet container owns its own class loader.  Thus, in
LM> the same JVM process space, we are able to support multiple customers
LM> running multiple versions of our code.

LM> The question deals with Log4j's ability to be configured differently for
LM> such customers, given the fact that they may be running in the same JVM
LM> process space, but under different web applications.

LM> So the question is - when Log4j is configured, what is the scope of the
LM> configuration settings?  I've looked through the documentation (which is
LM> excellent) and couldn't find this answer (maybe the answer is implied and I
LM> just didn't get it).  Is the scope the entire JVM process space, thus
LM> disallowing our scenario?  ... or following Ceki's servlet-based
LM> configuration pattern (http://jakarta.apache.org/log4j/docs/manual.html), in
LM> a servlet world (and if we include the Log4j jar's in each Web application),
LM> can we isolate the effect of configuring Log4j to distinct Web applications
LM> even though they run in the same JVM space?

LM> I'm thinking the question really comes down to - (a) how does Log4j
LM> internally maintain config settings (statics?), and (b) what is the effect
LM> from a scope perspective of this approach - e.g. can we isolate down to the
LM> web application level inside a single JVM space and servlet container.

LM> This question is very important to my organization, thanks for your time.

LM> Mike

LM> -------------------------------------------------------------------------------
LM> This message and any included attachments are from Siemens Medical Solutions 
LM> Health Services Corporation and are intended only for the addressee(s).  
LM> The information contained herein may include trade secrets or privileged or 
LM> otherwise confidential information.  Unauthorized review, forwarding, printing, 
LM> copying, distributing, or using such information is strictly prohibited and may 
LM> be unlawful.  If you received this message in error, or have reason to believe 
LM> you are not authorized to receive it, please promptly delete this message and 
LM> notify the sender by e-mail with a copy to CSOffice@smed.com.  Thank you

LM> --
LM> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
LM> 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>