Nice summary of the problem. Funny you should mention logback in
relation to the longstanding logging separation problem for static
logger references in shared libraries. As of v0.9.19 released last
week, logback provides an answer. See the chapter entitled "Logging
Separation" in the logback manual. The approach is a little convoluted
but should work assuming you can follow the reasoning behind it.
Cheers,
On 31/03/2010 6:49 PM, Jacob Kjome wrote:
For applications deployed as EAR files, you can't expect a webapp's
WEB-INF/lib/log4j.jar to be picked up by EJB's deployed outside that
webapp. In that case, you'd need to place it in some common upper level
(not at all in WEB-INF/lib) where both the webapp and EJB can see it.
Of course, unless you have a server that allows you to manage the
classloading behavior of an EAR file (i.e., set parent-last on the EAR
as a whole), not just a WAR file, then you can't depend on classloading.
This is where logger repository selectors come in. You can have a
global log4j.jar file (i.e. in the server's global classpath) and still
separate logger repositories. You just need to use some environmental
value as the key to the logger repositories in the selector, such as
thread, classloader, or JNDI. I think you might benefit from the
latter. One already exists in the log4j-sandbox tagged as Alpha3. See
the article I pointed to in my previous response for details.
There are caveats and you may find that shared libraries using
statically defined loggers (e.g., 'static final Logger logger =
Logger.getLogger("MyLoggerName")') end up logging to a different logger
repository than you expected. This occurs because the logger is only
looked up once, so the logger repository used will be the first one
looked up. If one webapp looks it up first, it's logger repository will
be used for the life of the library (i.e., until server restart). Other
apps using the library will have that library's logs going to the first
application's logger repository.
I know of no good way around this that I know of. Maybe Ceki has come
up with a better way over the years in his work with Logback? You might
ask on that mailing list.
Jake
On Wed, 31 Mar 2010 10:35:23 +0800
WM YEOH <[email protected]> wrote:
Hi Jake,
Thank you for the article.
I tried to put the log4j jar under application classloader level as well
as war WEB-INF/lib, and set the delegate to false in sun-web.xml, and
that
works fine. However, I got class not found exception when came across EJB
classes. I even specified the log4j jar in manifest file but no luck.
I couldn't find any useful information how to configure sun apps to load
parent-last. I am wondering is it no other way to have EJB classes
reference
log4j? Appreciate if you can again point me to the right direction.
Thank you.
Regards,
Wooi Meng
On Mon, Mar 29, 2010 at 10:57 PM, Jacob Kjome <[email protected]> wrote:
Research Logger Repository Selectors. Here's a resource to get you
started....
http://wiki.apache.org/logging-log4j/AppContainerLogging
Jake
On Mon, 29 Mar 2010 17:51:56 +0800
WM YEOH <[email protected]> wrote:
Hi there,
Current setup,
- App server - Sun Java System Application Server 9.1_01
- deploy one ear(own war) and another war applications in the same
stand
alone instance
I have setup in a way that each application has its own log4j.xml but
assign
to different log files, for instance, log4jA.xml -> A.log and
log4jB.xml
->
B.log. However, the debug message only written into one log file
instead
of
its designated log file. I could not package the log4j jar into the
war as
other classes in separate jar (within ear) used logger. Therefore, I
have
to
specified log4j jar in the server classpath. Which I believed that
would
be
the issue that causing the debug message not written to the correct log
file.
I am wondering is there any settings to solve the problem that I
faced. Or
is there any alternatives to solve the problem.
Appreciate anyone help me to solve the problem as soon as possible.
Please
let me know if you need further information.
Thank you.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
