On Wednesday 09 February 2005 23:34, you wrote: > As you are very knowledgeable in class loader > problems, I'd appreciate your comments and/or critical reviews.
First of all, I am very happy to see that someone else care, and care to such an extent and goes through all the pain to explain this to everyone to such detail. There are some minor mistakes, like <quote> Class loading problems encountered when using JCL fall into two main categories: </quote> (There exist three types of people in the world; those who can count, and those who can't.) Otherwise, I have not yet found any factual mistakes. And I would love to see the Example-7 completed ;o) JCL has been a favourite hate-object of mine for quite a long time, and I am surprised that it is still around and even seems to gain popularity... :o( Now, if you extend your own little pet into the same line of thinking just a little bit further, I think you will get the point of 'previous talks' on inherent issues in Log4J. Log4J as it is today is both an API and an implementation, and it is somewhat 'diffuse' what is what. This is being addressed, and that is good news. But, the same problem as exists with the JCL <-> Log4J relationship, exist between "Log4J core" <-> Appenders (e.g.), although at a much smaller scale. The Appenders must be loaded by the same classloader as Log4J, and that being at start-up. This is basically the same requirement that exist in JCL as well. <quote> this API must be located at the same level or higher in the class loader tree. </quote> In relation to JCL, you can argue that both containers and webapps uses both JCL and Log4J so the problem is extremely common, whereas "my scenarios" are less common, but in fact the same issue, that being that blindly loading classes from java.lang.String is not a good practice and a ClassLoader argument should be provided in such contexts. It is also necessary to have a proper API/Impl split, and basically push the impl classes as far down as possible (out of view) and keep the stable API classes higher up and shared. If I use UGLI's ULogger interface I can do this, push the API (ULogger) high up and push the implementation(!) (Log4J) far down, then Log4J needs to be treated as a big blob of implementation, with stuff like the mail.jar as a real dependency, since configuration changes in running servers, could later include SMTPAender and crash (have not checked how severly lately, but used to be pretty badly.). Now, I don't like to treat Log4J as a static monolithic blob of implementation, but ATM I have no choice. But this could change, and Log4J become a more dynamic creature, capable of adapting in non-stoppable servers. If a proper plugin model is employed for all things that are loaded dynamically through the configuration files, all this could be solved (not the JCL mess!) That would basically mean that the configuration specified a "plugin URI", which described the resources needed to load the plugin into Log4J, and Log4J managed the loading and unloading of those. That is what we do in DPML (http://www.dpml.net) for just about everything, and is not that hard. Log4J ends up being a 'big monolithic blob of implementation', but that is far from ideal. Unfortunately, the solution we have, called Transit, requires JDK1.4 and not generally available to Log4J, but something similar should be developed here. Current API and impl of our plugin system can be found here; http://paris.dpml.net/svn/development/main/home/transit/handler/src/main/net/dpml/transit/repository/Repository.java http://paris.dpml.net/svn/development/main/home/transit/handler/src/main/net/dpml/transit/repository/StandardLoader.java if you want to study what we have done. The StandardLoader uses a properties file to understand the plugin structure, esp what are API resources and what are the Impl resources. Find attached (if it goes through the mailing list) such descriptor for the Log4J provider in our logging system. (Note; this plugin does not define any API resources) Maybe I have strayed far too off-topic by now, and should halt it here. If Log4J wants to improve (irregardless of JCL issues), it should not blindly load classes either, but define a proper plugin mechanism which the configuration system uses (mind you, I have not looked at anything in Log4J 1.3 yet!). Hope I didn't bore everyone to death :o) Cheers Niclas P.S. The paragraph that was just added about UGLI doesn't have these kinds of problems doesn't convince me at all. If you bundle JCL with Log4J similarily to how you bundle UGLI+Log4J, wouldn't the same be true for JCL? I don't see anything dealing with classloaders...just like in JCL. I understand why it doesn't, but I don't understand how you claim there is a difference in this respect (except for the hash table).
# # Specification classifier. # dpml.plugin.meta.namespace = net.dpml dpml.plugin.meta.version = 1.0 # # Artifact descriptor. # dpml.artifact.group = dpml/metro/private dpml.artifact.name = dpml-logging-log4j dpml.artifact.version = SNAPSHOT dpml.artifact.signature = 20050209.162004 # # Type. # dpml.plugin.class = net.dpml.logging.log4j.Log4JLoggingFactory # # SPI dependencies. # dpml.artifact.dependency.spi.0 = artifact:jar:dpml/metro/private/dpml-logging-spi#SNAPSHOT dpml.artifact.dependency.spi.1 = artifact:jar:dpml/metro/public/dpml-logging-api#SNAPSHOT dpml.artifact.dependency.spi.2 = artifact:jar:dpml/metro/protected/dpml-logging-data#SNAPSHOT dpml.artifact.dependency.spi.3 = artifact:jar:dpml/metro/private/dpml-system-api#SNAPSHOT dpml.artifact.dependency.spi.4 = artifact:jar:dpml/transit/dpml-transit-main#SNAPSHOT # # Implementation dependencies. # dpml.artifact.dependency.0 = artifact:jar:dpml/util/dpml-util-i18n#SNAPSHOT dpml.artifact.dependency.1 = artifact:jar:dpml/metro/private/dpml-logging-criteria#SNAPSHOT dpml.artifact.dependency.2 = artifact:jar:dpml/util/dpml-util-criteria#SNAPSHOT dpml.artifact.dependency.3 = artifact:jar:dpml/metro/private/dpml-util-defaults#SNAPSHOT dpml.artifact.dependency.4 = artifact:jar:dpml/metro/public/dpml-configuration-api#SNAPSHOT dpml.artifact.dependency.5 = artifact:jar:log4j/log4j#1.2.8 dpml.artifact.dependency.6 = artifact:jar:dpml/metro/private/dpml-logging-log4j#SNAPSHOT # # EOF. #
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
