Hello Mark, Friday, December 13, 2002, 12:15:08 PM, you wrote:
MW> I have a concern about the specific init/shutdown code that is different MW> than this. The servlet related classes that we want to include in v1.3, MW> from which Jacob's init servlet and context listener are great starting MW> points, should be generic as to what logger repository they use, if they MW> want to use one at all. This means that they cannot contain any specific MW> code for ContextClassLoaderSelector, JNDIRS, or whatever. If Ceki's MW> comments on the user list yesterday (I haven't checked today's messages yet) MW> are any indication, each container may have its own repository selector MW> class. I would like to see that the servlet related classes can be MW> configured to use any selector the user wants it to. MW> I don't know what need to change to make this possible. Maybe the MW> RepositorySelector interface will need to add a couple more methods. Or MW> overridable methods in the servlet/listener for handling specific selector MW> calls. But we need to keep this in mind. I agree with this assessment. There should be a generic and configurable way to use alternate logger repositories based on, say..., config parameters for the init servlet or servlet context listener. I can look into what would be needed to do this. However, if you are thinking about including my Log4jInit servlet as-is, there is one thing that I added to my init servlet which might be Tomcat specific. Namely it tries to provide a convenience by creating a system variable based on the name of the context. Since there is no directly accessible way to get this from the servlet API (through ServletConfig), I grab the name of the temp directory from the current webapp and use that as a base for the system variable I create ( context.getAttribute("javax.servlet.context.tempdir"); ). For instance, if File IO is allowed (which I check for before doing this), for the context with a path of "/Barracuda" I grab the last directory in the value returned from the context attribute "javax.servlet.context.tempdir" and prepend that to ".log.home" and end up with a system varable called "Barracuda.log.home" which points to the WEB-INF/logs directory in the current location where the webapp exists on the filesystem. So, if you are deploying a webapp with the context path "/myapp" and want to use a FileAppender for logging, but don't' want to have to specify the physical location of the log file before runtime in your log4j.xml file, you can just assume that a system variable named "myapp.log.home" will be created upon application startup. So, you can just define your file appender like this: <appender name="A2" class="org.apache.log4j.FileAppender"> <param name="File" value="${myapp.log.home}/main.log" /> <param name="Append" value="false" /> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%-4r [%t] %-5p %c %x - %m%n"/> </layout> </appender> The thing is, I don't know if other appservers will store the temp directories with the same naming scheme as Tomcat does. So, I would certainly use my Log4jInit as a reference for how one might set up Log4j initialization, but I'm not sure I'd include it directly in the log4j distribution without some modifications to make it more generic. To be honest, I'm pretty sure I would continue to use my own version since some of the stuff like I mentioned above is too useful to give up. And as long as I know I am deploying in Tomcat, it provides some extra convenience for me. However, I'd definitely fall back to the one in Logj4 for other appservers where I can't count on some of the behavior that some of the features require. MW> I think the decision was made to move to jdk 1.2. I sure hope so, as I have MW> started using ArrayList and HashMap instead of Vector and Hashtable. MW> I think the use of WeakHashMap is fine. The objects will only be removed MW> after all strong references have been cut. After that we don't really care MW> when it gets removed from the Map, regardless of the vm's gc implementation. That's good. I'd rather not change that part. Jake -- Best regards, Jacob mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>