Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 33683 invoked from network); 27 Jun 2002 08:25:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 27 Jun 2002 08:25:00 -0000 Received: (qmail 7626 invoked by uid 97); 27 Jun 2002 08:24:31 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 7555 invoked by uid 97); 27 Jun 2002 08:24:30 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 7539 invoked by uid 98); 27 Jun 2002 08:24:29 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-Id: <5.1.0.14.0.20020627093834.02116cf8@mail.qos.ch> X-Sender: ceki@mail.qos.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 10:24:15 +0200 To: "Tomcat Developers List" From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: Re: Logging separation In-Reply-To: References: <5.1.0.14.0.20020626235045.02150ec0@mail.qos.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N At 15:15 26.06.2002 -0700, costinm@covalent.net wrote: >On Wed, 26 Jun 2002, Ceki G=FClc=FC 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=20 > while a > > servlet is running. There are two distinct TCLs. (I've tried this on=20 > 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=20 that the TCL in use while the code is executing the static class=20 initializer, as in private *static* Logger logger =3D Logger.getLogger(); is different than the TCL in use while executing the servlet init() or=20 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 =3D res.getWriter(); out.println(""); out.println("Hi from Hi."); out.println(""); } static void printTCL() { ClassLoader cl =3D 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=20 specification (i.e. in http://qos.ch/containers/sc.html) into log4j.jar. I= =20 then placed log4j.jar in jre/lib/ext. I also added a=20 LogManager.setRepositorySelector(new CRS(),..); statement within the=20 org.apache.tomcat.startup.Main class' main() method. I will be first to=20 admit this is extremely inelegant but good enough for educational=20 purposes. (This setup allowed me to ignore the intricacies of Tomcat's=20 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=20 danger that a bad servlet reconfigures log4j and has log4j write all sorts= =20 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: For additional commands, e-mail: