Hi Ceki, >> 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. Yeah this in my opinion is rather brain dead. I haven't actually been able to get a straight answer out of the Java folks on this one. Reasons they give for it being setup this way are either a) security concerns or b) to avoid infinite loops when classes are not found. Here is a pretty detailed explanation that a friend of mine put together about the issue: http://radio.weblogs.com/0100490/2002/03/06.html >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. Ognl (http://www.ognl.org) stands for Object Graph Navigation Language, the authors took the idea of Apple/NeXT's key-value coding (which is bean introspection on steroids) and extended it to allow for more operators and to operate on Collection interfaces. Kinda neat stuff. >How is your proposal different from log4j having its own class loader to load >extensions? I'd have to check but due to security issues I'm not sure that you can actually get a hold of the default class loader from a class loaded by the Extensions mechanism. If you can then yes having a custom class loader should solve 99% of the class loading issues. The real advantage of having a ClassResolver is that this allows the developer complete control for how custom classes are loaded, regardless of class loader being used. Regards, Max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
