David,
You are right to assume that there a different class loaders are different for jsps, servlets and EJBs in Weblogic. There is a different slightly different approach based on JNDI. Given that the JNDI name space is different for each application, one perhaps configure different resources for each of your application, that resource can then be used as the distinguishing factor for selecting logger repositories. I'll try this myself in a moment.
At 20:27 20.11.2002 -0500, Lu, David wrote:
Thanks for your reply, Jacob. I want to use log4j in a WebLogic environment with both EJBs and servlets. I also want to have this "separation" of logging so that if I have common components residing in many applications, those common components can be configured in one application without affecting the same common component in another application.I have used your Barracuda CRS and my approach is as follows: Put your CRS onto the system CP and have a Weblogic Startup class set that CRS as the logger repository to be used for the entire VM (WebLogic server). Put a ServletContextListener that will do a DOMConfigure() in each EAR and WAR file. I also happen to have a Servlet that will do a DOMConfigure() in its doPost() to dynamically reconfigure logging. This servlet is also in the EAR and WAR files. As my WebLogic server boots up, I can see that log4j is being initialized separately for each EAR and WAR file. That was encouraging since it led me to believe that the CRS was initializing a separate repository for each application (CL). However, after putting log4j statements in my EJBs, log4j complained that there were no appenders defined for loggers that were definitely defined in my log4j.xml. This suggested to me that even though there were separate repositories, the repository for my EJBs was not initialized with the loggers in my configuration file. As I thought about it more (with my poor knowledge of classloaders), this seems to make sense and would probably preclude using the CRS approach for EJBs (at least in WebLogic). My ServletContextListener lives in a Web Application classloader. Therefore, it's hierarchy is keyed in the CRS by its own CL. From my understanding, in WebLogic there is a separate CL for EJBs and servlets, with the former visible to the latter but not vice versa. Since there are two separate CLs, there will be separate hierarchies, one for EJBs and one for servlets. Since it was the servlet (listener) that initialized log4j, the key for that hierarchy will be the servlet classloader. The EJB, since it has its own CL, will have a separate repository that knows nothing about what the servlet did. In a past posting, Ceki said that using a servlet to initialize EJBs works. Nothing was said about using a custom repository selector. I assume that he made that statement assuming that I would keep one hierarchy for all applications instead of one hierarchy per application. Does this make sense to you? This would be a major blow to my strategy since my only other option is to place log4j.jar in each WAR/EAR file and *hope* administrators do not put a copy in the system CP. DAvid -----Original Message----- From: Jacob Kjome [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 5:12 PM To: Log4J Users List Subject: Re: WebLogic Repository Selector Question Hello David, Try the one I implemented. I works in Tomcat, but must exist in the the same classloader as the log4j.jar. In Tomcat, that means either in common/lib or shared/lib. Both can see each other so log4j.jar could be in common/lib and the jar containing Log4jCRS can be in either common/lib or shared/lib. Alternatviely, you can put a copy of log4j.jar in WEB-INF/lib. In that case, you need to make sure you also put the jar containing Log4jCRS in WEB-INF/lib as well. However, that doesn't really provide anything you don't already get by using log4j.jar in WEB-INF/lib anyway since that already provides a private environment for using Log4j for you app. Now, the other thing that needs to happen is that the classes using Log4jCRS *must* be loaded from the WebappClassloader. So, my Log4jInit servlet and Log4jApplicationWatch servlet context listener need to be inside a jar file in WEB-INF/lib. Here is Log4jCRS: http://barracuda.enhydra.org/software/cvs/cvsweb.cgi/Projects/EnhydraOrg/too lsTech/Barracuda/src/org/enhydra/barracuda/log4j/ Here are Log4jInit and Log4jApplicationWatch http://barracuda.enhydra.org/software/cvs/cvsweb.cgi/Projects/EnhydraOrg/too lsTech/Barracuda/src/org/enhydra/barracuda/webapp/log4j/ Also, you can see what the configuration for log4j looks like in the web.xml and log4j.xml here: http://barracuda.enhydra.org/software/cvs/cvsweb.cgi/Projects/EnhydraOrg/too lsTech/Barracuda/WEB-INF/ Now, keep in mind that the logger repositories created via Log4jCRS are keyed on the classloader. This means that when you do your configuration for each application, that application must be running in a separate classloader. I'm not sure exactly how that would work in an EJB container...but that is just because I haven't really written any EJB apps. Hopefully this helps with figuring out your issue. If nothing else, you can certainly use it for your webapps. Jake Wednesday, November 20, 2002, 3:21:02 PM, you wrote: LD> Has anyone tried the CRS in Ceki's containers document for WebLogic? LD> I've put that CRS class in a WebLogic startup class. LD> In my EJB.ejbCreate(), I have a statement like: LD> Logger logger = Logger.getLogger(StateEJB.class); LD> When ejbCreate() is called, I see the LD> public LoggerRepository getLoggerRepository() { LD> ClassLoader cl = Thread.currentThread().getContextClassLoader(); LD> Hierarchy hierarchy = (Hierarchy) ht.get(cl); LD> if(hierarchy == null) { LD> hierarchy = new Hierarchy(new RootCategory((Level) Level.DEBUG)); LD> ht.put(cl, hierarchy); LD> } LD> return hierarchy; LD> } LD> method getting called but I get a complaint from log4j saying there are no LD> appenders could be found for that logger and yet I see that logger in my LD> log4j.xml configuration file. LD> It's like that logger could not be found in my repository? LD> any ideas? LD> ********************************************************************** LD> This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please LD> contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, LD> is strictly prohibited. LD> TIAA-CREF LD> ********************************************************************** LD> -- LD> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> LD> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Best regards, Jacob mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
