From: Yannick M. <yan...@fa...> - 2005-02-10 14:34:01
|
Greg Wilkins <gregw <at> mortbay.com> writes: > > Ceki is quiet right and that JCL's discover mechanism is rather broken. > The standard jetty startup tries to avoid this by setting the system property to force a JCL factory - I assume this avoids the dynamic discover process, but > I have to say that I have not explicitly checked this. > But even IF jetty used log4j or UGLI or jgLoggin or whatever.... there would still > be the issue of child first class loading in webapps. Webapps will still provide their own log4j.jar or ugli.jar etc. and probably some will insist on a specific version of the jar. There will be disagreement if the webapp should participate in the same logging instantiation as the server - some want this and others do not. No, actually that's the whole reason behind using the ClassLoader>Factory cache, each classloader has it's own private log implementation. So two webapps can each have it's own private version of log4j, for example. In that aspect the JCL discovery system is quite good, the problem comes from the fact that they use the Hashtable to map ClassLoader to Factory, which is the root of all the JCL evils. However that is easily solved by using a WeakHashMap instead ( losing 1.1 compatibility by doing that ). I used the same concept in jlogging, but using the WeakHashMap instead. Also for my JCL integration ( which is a custom JCL Factory ), i replaced the JCL Hastable with a no-op hashtable so that it does not leak classloaders anymore I'm not sure about how UGLI does it however. > I am very tempted to just run away and go back to using native jetty logging and > then let the webapp implementors fight it out!!!! That is not a bad idea.. Just make it an interface so that the implementation can be replaced with another one. |