Re[2]: ClassLoader Repository Selector inclusion

[Jacob Kjome <ho...@visi.com>]

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:hoju@visi.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>