I think you've missed the point of what is being done with "javax.servlet.context.tempdir".
Yes, I assumed you were using it for it's intended purpose.
It is absolutely, utterly, guaranteed that any and all containers claiming to have support for the servlet spec *will* provide a temporary directory that is unique for each web application. If they don't, they aren't compliant. I have no worries about that.
Here is what you are missing. I don't care about using the actual directory. I just care about the directory name. What I was trying to accomplish was a way that one didn't have to keep multiple configuration files in sync with the name of some property...and I also needed to have some pretty decent assurance that that name wouldn't exist already as a system property. Since webapps must have unique context path names, that turns out to be a pretty good way to name system properties. However, the servlet spec doesn't provide any direct way to obtain the servlet context path (eg... /mycontext) via the ServletContext, which is all I have to work with in the servlet context listener. However, I can grab the value of the system property "javax.servlet.context.tempdir". As it turns out, the way Tomcat name tempdirs is very consistent. For instance, a context with the path of "/mycontext" would have a tempdir named something like this...
C:\Java\Apache\Jakarta\tomcat-4.1.24\work\Standalone\localhost\mycontext
So, I just grab the string following the last index of the value returned by File.separator and, low and behold, I've obtained the name of the currently running context.
Is this any different from ServletContext.getServletContextName() (available in 2.3) or would that be equivalent when available?
I take that and append ".log.home", use that as a system property name, and set the physical path to where logs should be written for that context which could either be the default of the WEB-INF/logs of the webapp or a user defined path.
What breaks down in other servlet containers is that the string following the last index of the value returned by File.separator for a context with a path of "/mycontext" might be "some-other_random-string_having-nothing_to-do_with-the_name-of_the-context_path". Now, in one sense, this is fine because it is unique since we don't want to accidentally overwrite a system property being used by some other application. However, it is far from predictable and might change with each deployment of the webapp in some containers. We need to be able to put something we can count on in log4j.xml such as the following an know it will just work...
<param name="File" value="${mycontext.log.home}/main.log" />
In summation, I require...
1. a name that is reasonably guaranteed to be unique in the VM
- this is achieved by using the name of the context path which must be unique within the container so a system property named after something that is already unique is pretty well guaranteed to be itself
2. not have to specify this name in multiple configuration files. Only log4j.xml.
- It is extra work to have to change things in two places. To avoid this, instead of requiring the use to have to provide a context-param with the name of the system variable, I just have the configuration derive it on its own. This also prevents arbitrary naming that might not be as unque in the VM as one might hope.
3. the name must be predictable
- one has to reference a system property name in log4j.xml that they can be assured will exist at runtime, otherwise it is of no use. Defining a naming scheme based on [context path].log.home is entirely predictable and the dynamically derived system variable name works for this every time under Tomcat.
Let me ask some stupid questions, since I do not really know the purpose of the ContextClassLoaderSelector:
How does this work outside of a servlet container? Or is it only intended to run inside a container? What are the other configuration files you refer to? Might there be a way to point both places to the same config file? What happens if tomcat changes the way it implements the temporary directory mechanism?
Like I've said, #3 breaks down in containers outside of Tomcat which is why I plan to add a context-param which, if specified, will override the dynamic generation of the system property. Of course this, in turn, breaks down #2, but I don't see any way to get around that. If one continues to use a naming scheme that matches something like [context path].log.home then, at the very least, #1 and #3 continue to hold true.
Hopefully that clears things up. If I am just being totally dense and missing your point (which is entirely possible), please point out how #1, #2, and #3 are better achieved by using the "java.io.tmpdir" system property.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]