RE: WebLogic Repository Selector Question
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
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/toolsTech/Barracuda/src/org/enhydra/barracuda/log4j/
Here are Log4jInit and Log4jApplicationWatch
http://barracuda.enhydra.org/software/cvs/cvsweb.cgi/Projects/EnhydraOrg/toolsTech/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/toolsTech/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,
Jacobmailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: WebLogic Repository Selector Question
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
RE: WebLogic Repository Selector Question
Unfortunately, I can tell you very little about either Weblogic or logging in EJB's because, like I said before, I haven't really written any J2EE apps. The one thing that should hold true is that you shouldn't need to worry about log4j being in the system classpath if you put a copy of log4j in each webapp's WEB-INF/lib directory because, unlike other classloading schemes, the way webapps work is that they look to their own classloader first before looking to other classloader to load libraries. This works to your advantage because then log4j will be loaded by each WebappClassloader instead of all apps looking at the one specified on the sysystem classpath. At least that is the way it works in Tomcat, but I believe the servlet spec requires that behavior. As as far as EJB's go, I'm not sure what to do there? There must be others on this list who have used log4j in EJB's and probably a few who have used log4j from within Weblogic. Maybe they can share their experiences. So, I think your webapps are all set, but for EJB's you may have to modify Log4jCRS or think of something else that you might want to key the different logger repositories on. Let me know if you find anything or improve up on my code. I'd love to figure all this out as well. Jake At 08:27 PM 11/20/2002 -0500, you 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
