At 15:15 26.06.2002 -0700, [EMAIL PROTECTED] wrote:
>On Wed, 26 Jun 2002, Ceki Gülcü wrote:
>
>
> > A difficulty I encountered while implementing the solution outlined in
> > http://qos.ch/containers/sc.html is the difference of TCL while the the
> > static class initializer of a servlet class is executed and the TCL
> while a
> > servlet is running. There are two distinct TCLs. (I've tried this on
> Tomcat 3).
>
>That's very strange - Jdk12Interceptor is setting the TCL before
>init/destroy/service, and it should be the same.
I don't know what Jdk12Interceptor is. However, I have clearly observed
that the TCL in use while the code is executing the static class
initializer, as in
private *static* Logger logger = Logger.getLogger();
is different than the TCL in use while executing the servlet init() or
servlet doGet() methods.
One can be easily convinced of this by running the following servlet:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Hi extends HttpServlet {
static {
System.out.println("Hi: static initializer"); System.out.flush();
printTCL();
}
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
System.out.println("Hi.doGet()"); System.out.flush();
printTCL();
res.setContentType("text/html");
PrintWriter out = res.getWriter();
out.println("<html><body>");
out.println("Hi from Hi.");
out.println("</body></html>");
}
static void printTCL() {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
System.out.println("HI: TCL is "+cl); System.out.flush();
}
public void init() {
System.out.println("Hi.init()"); System.out.flush();
printTCL();
}
public void destroy() {
System.out.println("Hi.destroy()"); System.out.flush();
printTCL();
}
}
"Hi" is a trivial servlet but nonetheless instructive.
>What code are you using ?
What I have done was to add the CRS class as it figures in the
specification (i.e. in http://qos.ch/containers/sc.html) into log4j.jar. I
then placed log4j.jar in jre/lib/ext. I also added a
LogManager.setRepositorySelector(new CRS(),..); statement within the
org.apache.tomcat.startup.Main class' main() method. I will be first to
admit this is extremely inelegant but good enough for educational
purposes. (This setup allowed me to ignore the intricacies of Tomcat's
build file.)
>Regarding the document - it looks great.
Thank you.
>One missing part is how the
>JMX part of log4j will name it's objects ( i.e. the Hierarchy must
>have a name ). The container should be able to set this name when
>it creates the hierarchy ( with "vhost:/cpath" for example ).
I agree. There will be a separate JMX document where this will be covered.
>BTW, I will try to implement this at the coyote level, since this
>is likely to be usefull for 3.3, 4.x and 5.0. It will require
>the ADD_CONTEXT callback to work ( that's needed for jk autoconf
>anyway ), and probably few other small changes.
>
>One important issue not covered in the document - the possible
>interaction with the sandbox. If log4j is in the common path,
>it'll probably have high permissions. I assume you don't use
>doPriviledged() in the code, but you probably use some
>queue or similar code - and that may potentially get code to
>be executed with the container permissions, possibly
>allowing untrusted servlets to do bad things.
No, there are no doPriviledged() calls in log4j code. There is indeed a
danger that a bad servlet reconfigures log4j and has log4j write all sorts
of garbage at the wrong places.
>On the same line, it is very likely log4j will not work
>in the sandbox without a doPriviledged() unless the webapps
>have write permission to log/.
>
>Glenn is much better at explaining all this - but it's a serious
>issue.
>
>Costin
Thank you for studying my proposal. I certainly appreciate the interaction.
--
Ceki
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
