Re: [Hibernate] JCL classloading headache

[John Franey]

Max, 1: Centralize all logging configuration to a single file: jdk1.4 logging: By default, jdk logging finds config file in jre/lib directory, but this doesn't put control of the configuration into the rcp provider unless the provider is also delivering a full jre.  Better to set the java.utils.logging.config.file property. log4j:  By default, log4j will find the config file 'log4j.properties' in the classpath.  Relying on this in Eclipse is possible (you can use eclipse classloading buddy policy), but is non-deterministic because you can't predict which pluguin Eclipse will find the file.   Better to set the command line property: log4j.configuration. At productization time, command line properties for your rcp product are set in the launching arguments section of the configuration page in the product editor.  During plugin development and testing, you can set command line properties in the VM arguments text panel your plugin's Run configuration.  Find the Run configuration by selecting Run... from the Run workbench menu. 2: Appender in hibernate plugin can be found by the log4j plugin: Assuming there is a log4j plugin.....  The log4j plugin must have a Buddy Policy that will make visible appenders contributed by other plugins.  I choose 'registered': Eclipse-BuddyPolicy: registered in its Manifest.MF file.  Then, any plugin that has an appender would register as a buddy with the log4j plugin with Eclipse-BuddyRegister: org.apache.log4j  This assumes the log4j plugin is named org.apache.log4j.  This is a good assumption because McAffer's book promotes the convention that a code library plugin is named for the java package within. In reality, there isn't an eclipse log4j plugin.   McAffer's book suggests this would be a job for Apache logging project. 3: How to swap among logging frameworks: log4j, jdk1.4, SimpleLog, nlog4j Assume there are code library plugins for slf4j, one plugin for each framework that slf4j supports.  For example, org.slf4j.log4j is a plugin that contains interface code to log4j, org.slf4j.jdk14 contains interface code for jdk logging api.  Also, each of these plugins contains a copy of slf4j's commons-logging implementation.  All of these plugins export the org.apache.commons.logging packages and the org.slf4j packages. Your plugin that invokes the logging api must import the logging api.  Use 'import' not 'required' to declare to eclipse your plugin's dependencies.  'Required' means your plugin depends on a specific plugin by name; 'import' means your plugin depends on any resolved, enabled plugin that exports the named packages.  In the dependencies page of your plugin's manifest editor, put the logging api packages in the 'import' panel: org.apache.commons.logging, org.apache.commons.logging.impl, org.slf4j, org.slf4j.impl, org.slf4j.spi. I hope you have setup a plugin development target.  It isolates your development bed from your eclipse installation plugins.   Load the log4j plugin and the org.slf4j.log4j plugin into your target.  To swap from one framework to the other, say from log4j to jdk logging, load and enable the org.slf4j.jdk14 plugin into your target, and disable the org.slf4j.log4j plugin you have been using. I think the swap capability is cool but not something an rcp end user would be interested in taking advantage of.  For a developer of a code library plugin, like hibernate or its dependencies, this capability means that the rcp developers which use your plugins won't be tied to log4j.  I also think this capability is useful for hibernate, like for swapping multiple cache implementation plugins, but I don't know enough about the cache api and am guessing. Sidebar: Creating a code library plugin is very easy and takes only a few minutes.  Create a new project -> plugin development -> plugin from existing jar files, select the jar files to be included, modify the manifest (imports, exports), and thats it.   Wouldn't it be nice if providers of code libraries did this for you? I can send the MANIFEST.MF file for each of the code library plugins I've created.  Is this the right forum? John Max Rydahl Andersen wrote: I also found solutions to some other issues like: how to centralize all  logging configuration to a single file, and how an appender in hibernate  plugin can be found by the log4j plugin, and how to swap to a different  slf4j implementation library so jdk logging, nlog4j or simple log I'm willing to share the details if you are interested. I'm definitly interested. /max John Max Rydahl Andersen wrote: yes, i also find slf4j interesting, but afaik it won't help solve the logging problem while other components i use uses common logging. And it will also still have issues with duplicate configuration etc.,  but  im not sure. /max Hi. When developing eclipse plugins, I ended up with a severe limitation   when a plugins makes reference to the apache-commons-logging library AND each other. Well, digging around I found the slf4j library  (http://www.slf4j.org/)  that seems to solve my problem. The cenario where the problem arose was eclipse, where my plugin may reference or not hibernate's plugin, and both had apache log. Each  plugin MAY exist without the other, so each one must have logging, but when  they are both used, we got classloading problems. I'm testing this new library now in the java.tri plugin. It may be   usefull to the hibernate-tools. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel