java.util.logging.* and namespace/classloading/security issues

["j.random.programmer" <ja...@yahoo.com>]

Hi:

If and when JDK 1.4 becomes the minimum platform 
for Tomcat, the following must be kept in mind:

The java.util.logging framework provides a global
namespace that by default is tied to the system 
classloaders. J2EE apps should modify this so that
the java.util.logging namespace is specific only
to the app/context specified classloader. 

Here's why:

Loggers are installed and managed by names that 
are common to all classes in the JVM. For example, I 
can install a logger called "Foo".

Now any virtual host or servlet context running in
a J2EE container can access that logger by the name
"Foo". It's also possible for any code to get a
enumeration of all installed loggers in the JVM so
I don't even have to know the name beforehand.

Suppose I am a hosting company and I host 2 seperate
domains using the same J2EE container. Suppose these
domains are called www.a.com and www.b.com

What happens now is that www.b.com can redirect,
change or view any loggging statements made by any 
code running inside www.a.com. To prevent just this 
sort of thing, the servlet spec mandates seperate 
classloaders for different virtual hosts and even 
different contexts within the same host.

The logging documentation has this to say:

------------------ quote ----------------------
For J2EE applications, the J2EE container
typically controls the environment and provides
the shared services that are used by all the
contained components. All the �global� state in
the Logging APIs is maintained in the LogManager
class. The Log-Manager APIs allow a program to
substitute its own version of the LogManager
class. Thus a J2EE container can replace the
standard LogManager class with its own subclass
that may implement different rules for managing
"global" state. For example, a J2EE container
might provide separate logging namespaces for
logically distinct applications that are sharing
the container.
------------------ end quote ------------------

This can be found in Section 2.19 ("J2EE Issues")
at the following URL:

http://www.jcp.org/aboutJava/communityprocess/review/jsr047/spec.pdf

Note, not changing the LogManager namespace also
implies
ClassCastExceptions (across reloads) in the same web
application.

Here's a bug report on the same subject (although
somewhat harshly worded):

http://developer.java.sun.com/developer/bugParade/bugs/4744186.html

Tomcat must load all java.util.logging classes via
seperate classloaders because even though tomcat
itself does not use java.util.logging internally, the
client code (i.e., my servlet code and 3rd party
library code *does* use java.util.logging).

Best regards,

--j


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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