RE: Re[2]: Log4j Configuration with Servlet
Howdy, If we think it is a good, useful example of a repository selector, and to be useful it needs to live at the same location as the log4j jar, why should we not include it in the official distribution? When does it become core, in your opinion? In my mind, it may be possible that the log4j includes several different, useful repository selectors, each with their own use, maybe in their own package o.a.log4j.selectors or something. It becomes core when it has: - Been part of the contrib distribution (or its own log4j add on, or however it's packaged) for a bit. - Been tested more extensively, preferably with test cases that are part of the distribution. - Been used by people, and hopefully generated some questions and discussions on the user mailing list. I don't doubt the quality of the code. I do think it's a bit specific (to tomcat 4.x) right now, and that may need tweaking, or alternatively we may need to write JBoss/Resin/Weblogic/whatever selectors, or maybe a more universal JNDI repository selector like Ceki suggested. I also think it's a bit new, and I want to maintain log4j's reputation of outstanding stability and reliability. Accordingly, I think it should be its own jar, with the stipulations that: - It's new - It's experimental - It needs to be in the same class loader as log4j.jar - It hasn't been tested on anything other than tomcat 4.x - We want feedback on it This type of issue is always open to interpretation, but I'd rather err on the conservative side before throwing things into the log4j core package. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Log4j Configuration with Servlet
Yep, There is no harm in using Log4j within WEB-INF/lib even if Log4j exists in a parent classloader. It doesn't affect any other apps the the current app is free to use whatever version of the jars they want. In the context of using a repository selector, putting log4j.jar in the WEB-INF/lib is really of little use since it even the default logger repository will be unique to that application only. I just wanted to point out that the custom repository selector, if used by the webapp's configuration, must be in the same location as the log4j.jar and if the log4j.jar is included in WEB-INF/lib, then so must the custom repository selector otherwise you run into weird classloading errors. So, put log4j in WEB-INF/lib or in a parent classloader. Whatever. Just be diligent about taking jar dependencies into account. Jake At 10:35 AM 12/13/2002 -0500, you wrote: Howdy, That's a good point. At some point in time, it should be documented that any container should have one and only once copy of log4j.jar+associates. Once the selector approach is adopted, putting log4j.jar in WEB-INF/lib must be strongly discouraged. I agree with the first part, not the second. In my experience, the case of one webapp per container is common (not to mention recommended by some people, for security and other considerations). In that case, I'd say it's not only fine but a good idea to put the log4j core and any optional modules in /WEB-INF/lib. If you're deploying your app in a .war file to heterogeneous servers, this is easier and more portable than putting the log4j files in the (non-standard) common library location in each server. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Log4j Configuration with Servlet
Howdy Jacob, Actually, If you look in my post, I mention more than just the Log4jInit servlet. I also mention a servlet context listener (SCL) called Log4jApplicationWatch. I actually use that currently to do cleanup such as shutting down loggers and appenders of the currently used logger repository inside contenxtDestroyed(). Now, I could move the initialization code from the init() of the Log4jInit servlet to the contextInitialized() method in Log4jApplicationWatch. However, that would preclude using this type of initialization in a servlet-2.2 container. However, I definitely think that using contextInitialized() is the way to go if you are assured that the container supports servlet-2.3. Yes, I think that the code could/should be structured so that you could use one set for servlet 2.2 and another set for servlet 2.3, with appropriate documentation, etc. Actually, the main thing I'd propose is having Log4jCRS (Log4j Contextual Repository Selector) be included with the Log4j distribution. The reasons for this are described in my post that Mark linked to above. I agree with this. If nothing else, it is good example of a repository selector. Log4jInit and Log4jApplicationWatch need to be in a separate jar which is included in each app's WEB-INF/lib. I have added all the magic I can to make this work reasonably well. Hm. We could look at how to package things to make sense for use. If Ceki or you (Mark) can figure out a way where Log4jCRS can work without Log4jInit and Log4jApplicationWatch existing in each app's WEB-INF/lib, then they can be included in the log4j.jar. I would have to defer to Ceki on this. I think he is more expert on this than me. BUT, I do think we should move forward with getting some form of this code into the v1.3 release. I designate Jacob as lead for this effort. :-) I will be point for reviewing submitted code (though I hope others will help with this), checking it into cvs, updating the build script to package it correctly, etc. Jacob, do you think you can make an official apache submission (with all the correct apache headers, etc)? -Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Log4j Configuration with Servlet
Actually, the main thing I'd propose is having Log4jCRS (Log4j Contextual Repository Selector) be included with the Log4j distribution. The reasons for this are described in my post that Mark linked to above. I know this is not a vote, but +1 on that. As part of the contrib tree, not core, for now. As a separate jar. With documentation saying it must be loaded by the same classloader as the core log4j jar. And thanks again to Mr. Kjome for the contribution. Yoav, If we think it is a good, useful example of a repository selector, and to be useful it needs to live at the same location as the log4j jar, why should we not include it in the official distribution? When does it become core, in your opinion? In my mind, it may be possible that the log4j includes several different, useful repository selectors, each with their own use, maybe in their own package o.a.log4j.selectors or something. just wondering, -Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Log4j Configuration with Servlet
One possible one-shot-kill-all-birds solution is to use the JNDI space. See the updated version of http://www.qos.ch/logging/sc.html (in particular JNDIRS). What do you think? I also suggested the JNDI solution in commons-dev in a somewhat different context. It seemed to be well received. Should we consider adding the JNDIRS to v1.3 of log4j in a/the selectors package? -Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Log4j Configuration with Servlet
At 15:54 12.12.2002 -0800, Mark Womack wrote: One possible one-shot-kill-all-birds solution is to use the JNDI space. See the updated version of http://www.qos.ch/logging/sc.html (in particular JNDIRS). What do you think? I also suggested the JNDI solution in commons-dev in a somewhat different context. It seemed to be well received. First, it should be noted that one-shot-kill-all-birds solution was meant metaphorically. Birds are wonderful beings that should not be harmed. In general no animals should be harmed except perhaps mosquitoes. (I don't like mosquitoes.) Should we consider adding the JNDIRS to v1.3 of log4j in a/the selectors package? Yes, we can reasonably do that. However, I am unsure about the maturity of any of these approaches without proper testing/analysis. Consequently, we should include these selectors assuming that they are visibly marked as experimental. Their inclusion might spur Container developers to refine the selectors in a way only they can given their intimate knowledge of their own Container. For example, according to Adrian Brock (a key JBoss developer), JNDIRS will not work for MBeans because MBeans do not have a reserved JNDI java:/comp context. With his knowledge of JBoss, he came up with quite a complete, albeit sophisticated, solution. This was during a face to face conversation. I did not jot down the solution and I can't even begin to remember what it was. I am afraid that none of the selectors we propose in log4j proper will be universally applicable to all J2EE containers. Container developers will have to provide some level of support on their own. However, we can show part of the solution, letting Application servers/Web containers to fill in the rest. Coming back to the question, yes, we should create o.a.l.selectors but not ship it as part of the official distribution as the proposed selectors may be half-baked. Half-baked solutions eventually boomerang causing more harm than good. (I hope the above is not too confused.) -Mark -- Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Log4j Configuration with Servlet
Yes, we can reasonably do that. However, I am unsure about the maturity of any of these approaches without proper testing/analysis. Consequently, we should include these selectors assuming that they are visibly marked as experimental. Their inclusion might spur Container developers to refine the selectors in a way only they can given their intimate knowledge of their own Container. I think that sounds reasonable for all the selectors we have proposed so far, given that each has specific limitations. We can document the entire package as experimental in the package.html, class javadoc, etc. For example, according to Adrian Brock (a key JBoss developer), JNDIRS will not work for MBeans because MBeans do not have a reserved JNDI java:/comp context. With his knowledge of JBoss, he came up with quite a complete, albeit sophisticated, solution. This was during a face to face conversation. I did not jot down the solution and I can't even begin to remember what it was. I am afraid that none of the selectors we propose in log4j proper will be universally applicable to all J2EE containers. Container developers will have to provide some level of support on their own. However, we can show part of the solution, letting Application servers/Web containers to fill in the rest. So, do/should we expect to have the container implementors provide log4j solutions as part of their product or do we expect them to submit the solutions to the log4j project so that they can be distributed as part of the log4j distribution? Could we foresee an o.a.l.selectors.JBossSelector as part of the official log4j distribution and maintained by someone at JBoss? The code in the log4j servlet package will need a generic mechanism to know what repository selector class to use in the specific environment it is deployed within. It cannot assume any specific selector class like some solutions do today. Maybe we can do this as part of the servlet/context init params. Coming back to the question, yes, we should create o.a.l.selectors but not ship it as part of the official distribution as the proposed selectors may be half-baked. Half-baked solutions eventually boomerang causing more harm than good. (I hope the above is not too confused.) I understand. I will make the appropriate build changes to reflect this as we add the selector package. What else can we do to champion log4j RepositorySelector support in all the major J2EE containers? -Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
