Hi Ceki, Thank you for the guidance.
I think I better start all over again what was the actual problem to give you a better picture. I am currently upgrading the sun one apps server from 7.1 to 9.1 (in UNIX platform), common-logging.jar, jakarta-log4j-1.2.6.jar and log4j-1.2.15.jar are currently specified in the server classpath. The logging problem occurred after upgraded to 9.1. I have an EAR file containing few jars (EJB involved) and a war file deploying in a standalone instance. I have another war file deployed within the same instance, meaning there are 2 apps running in one instance. When the instance startup, there are suppose to have 2 log files, for instance A.log and B.log. However, all the loggers only written in a single log, take A.log as an example. Both apps have their own initServlet to load the log4j configuration files. I need some answers from you in order to clear my doubts, - is logback my only solution? - can I used log4j-1.2.15 instead of slf4j-api-1.5.11? - I am not too sure how logback.xml is been read, initServlet triggered to lookup the xml file or no sevlet needed only specified in web.xml? - what should be the value for <env-entry-value>, just the xml file name or should I include the path as well like /WEB-INF/classes/xml/A1.xml - by looking at the logback-starwars project, it looks very simple. And I assume there neither to add -Dlogback.ContextSelector=JNDI nor Dlogback.ContextSelector=myPackage.myContextSelector in system property? - is "myPackage.myContextSelector" means custom context selector written by me? Appreciate if you can help me to understand more about the logback concept and how can I solve the problem. Hope to hear from you soon. Thank you. Regards, Wooi Meng On Thu, Apr 1, 2010 at 6:40 AM, Ceki Gülcü <[email protected]> wrote: > 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] > >
