tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Logging separation
Date Thu, 27 Jun 2002 08:24:15 GMT
At 15:15 26.06.2002 -0700, costinm@covalent.net 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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message