This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
On or about NB6.1 Dev build 200803220007, Spring Framework module (java2\modules\org-netbeans-libs- springframework.jar) started including version 1.1 of Apache Commons Logging JAR (java2\modules\ext\spring\commons- logging-1.1.jar) in its manifest's Class-Path extension. Even though a dash was specified for OpenIDE-Module-Public- Packages (indicating no packages are to be exported), the System Classloader (Thread Context ClassLoader) can still access the 1.1 Commons Logging classes (http://bits.netbeans.org/dev/javadoc/org-openide- modules/org/openide/modules/doc-files/classpath.html#syscl). Modules which depend on standard NB 6.1 Apache Commons Logging 1.0.4 module (org-netbeans-libs-commons_logging.jar) are now broken when Apache's LogFactory.getLog() is called because LogFactoryImpl uses the Thread Context ClassLoader to load the implementation class and finds it from the Spring Framework Module ClassLoader. However, the org.apache.commons.logging.Log interface loaded by netbeans-libs-commons_logging Module ClassLoader fails the isAssignableFrom() test with the implementation class, causing severe problems downstream. Was the standard NB 1.0.4 based Apache Commons Logging not adequate for the Spring Framework? SEVERE [org.openide.util.RequestProcessor] org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385) Caused: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529) Caused: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:370)
Spring has been using 1.1 for awhile now Which modules use 1.1? Can you please provide a use case
Besides Spring, I'm not sure which other module uses the 1.1 Apache Commons Logging. We (at SOA/BI Java CAPS) are not trying to use any specific version but just depending on the standard NetBeans Apache Commons Logging module (org-netbeans-libs-commons_logging.jar) which happens to be 1.0.4 based. However because of the System ClassLoader, the 1.1 version of Log Implementation is retrieved from the Spring Framework Module and tested against the 1.0.4 version of Log Interface in the LogFactoryImpl.getLogContructor(), resulting in error for our modules. When we disabled the Spring Framework module JARs, everything worked as expected. We (Java CAPS and Spring) were all happily coexisting prior to the 200803220007 Dev build.
Possibly this change <http://hg.netbeans.org/main?cmd=changeset;node=9505aae8cc79> caused the conflict, so if the library is not moved to a separate integration module this could solve this ?
Spring in 6.1 requires version 1.1 of apache commons-logging
I think, ideally commons logging should really fix the incompatibility of package names in different versions of the library
If this conflict really didn't occur until after 3/22 then changeset 9505aae8cc79 may have to be reverted
Fixed in 42b687c8e6e7 by not putting spring.jar and commons_logging.jar on the module classpath. This is not the right fix, since the reason to have a separate wrapper module was to expose the Spring API. Better would be to upgrade libs.commons_logging to 1.1 and remove commons_logging.jar from libs.springframework. I opened a discussion about that, so downgrading to P3 and leaving open for now.
You might want to vote for issue #118020.
No plans to upgrade commons_logging.jar to 1.1 in NetBeans 6.1, so making as enhancement.
Created attachment 59502 [details] Proposed change
I propose to upgrade the version of commons-logging.jar in libs.commons_logging from 1.0.4 to 1.1. According to the announcement of 1.1, this should be a backward compatible change: http://www.mail-archive.com/announce@apache.org/msg00251.html Please review. No, this is not an April Fools' joke.
As users of commons-logging.jar, visual web and mobility might be interested.
update: discussions have been going on with the Visual Web team
Unless there are any more comments, I will commit tomorrow.
311fb5d453e3