At 18:22 12.04.2002 -0700, you wrote: >Hi, > Long time developer with log4j (since the 0.9 days), first time >poster. An issue that I have stumbled across when using log4j with the 1.3 >jdk is that you can't drop log4j.jar into a java extensions directory and >then use any custom pattern layouts or custom appenders that are found in >the regular class path due to security/classloader-weirdness issues. This >means that the log4j.jar must always be included in the main classpath when >custom appenders/pattern-layouts are used that also appear in the main >classpath.
This is a direct result of the classloading delegation model and the fact that the Extentions classloader is the *parent* of the System classloader. In any case, the problem that you mention is a real and an important one. > The way that I have seen this handled with other packages (Ognl >comes to mind) is to have an interface say ClassResolver that will resolve >requests for loading classes. If the class resolver isn't set then the >regular forName method is used. This has the benefit of being able to put >log4j in the extensions directory and then set a ClassResolver object loaded >from the main classpath at startup which can resolve class for name requests >for both the main and extensions class loaders. I am not familiar with Ognl. How is your proposal different from log4j having its own classloader to load extensions? -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
