Agreed, I understood that Jetspeed removed all commons logging but this is the dependency tree generated by the command given:
[INFO] [dependency:tree] [INFO] com.visionsolutions.vip.portal:ui-portal:war:1.0.0 [INFO] \- org.apache.portals.jetspeed-2:Jetspeed-dependencies:pom:2.2.0:compile [INFO] \- org.apache.portals.jetspeed-2:jetspeed-serializer:jar:2.2.0:compile [INFO] \- org.apache.ddlutils:ddlutils:jar:r551445-patched-75:compile [INFO] \- commons-logging:commons-logging:jar:1.0.4:compile [INFO] David Just l Software Engineer l Vision Solutions l +1 (507) 529-5939 l [email protected] The contents of this e-mail (and any attachments) are privileged and confidential. Unauthorized use is strictly prohibited. ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 27 seconds [INFO] Finished at: Wed Sep 09 15:39:50 CDT 2009 [INFO] Final Memory: 20M/508M [INFO] ------------------------------------------------------------------------ Which if I'm understanding correctly states that Jetspeed-serializer is including apache ddluitils which is including commons-logging. -----Original Message----- From: Ate Douma [mailto:[email protected]] Sent: Wednesday, September 09, 2009 3:16 PM To: Jetspeed Users List Subject: Re: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log Hi David, I'm trying to understand your setup but its not entirely clear to me. The below "Request Error Diagnostics" report indicates to me you're using Jetspeed 2.2.0 (or trunk) as that is a new feature since 2.2.0. But, further down you mention using commons-logging-1.0.4.jar as being "the same version that comes with Jetspeed". However, since Jetspeed 2.2.0 we've completely *removed* all commons-logging usages within Jetspeed (and all Apache Portals projects for that matter) because it has been too much cause of trouble when used within a portal environment. Instead, we are now only using slf4j instead. For more background information on this, see: https://issues.apache.org/jira/browse/JS2-972 Actually, your error situation looks very much like exactly what we're wanted to solve by replacing commons-logging with slf4j. So, if you do have a commons-logging-1.0.4.jar usage in your (custom?) build of Jetspeed, I think it must have come in through additional/custom maven build dependencies (possibly only transitively). And, especially if that ends up being mixed with a jcl-over-slf4j jar in the same classloader you might indeed hit an exception similar to what the report says below. I suggest running the following command to get a precise view how maven resolves and derives its dependencies from the root/master project or specific sub projects/modules individually: $mvn dependency:tree -Dincludes=commons-logging Note: if you do have a hard dependency on commons-logging *api* either through your own code or some third-party library, you can still "solve" that by using the jcl-over-slf4j "bridge" library instead of commons-logging itself (which you then of course need to exclude from being pulled in as dependency). HTH, Ate David Just wrote: > Does anybody have any experience with getting this error: > > > Request Error Diagnostics > > Error ID > > > > FZE7KOM9 > > Message > > > > 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. > > Path > > > > /ui/portal/ > > User > > > > admin > > > > > > I've written a portlet that uses the PageManager service to create a > folder in the user's home folder. I'm using commons-logging 1.0.4 in > the portlet which is the same version that comes with Jetspeed. If I > remove logging jar file from my portlet it fails to start because it's > classes cannot find the logging jar that is provided by Jetspeed. If I > keep the jar in the portlet when I call the update method of the > PageManager it throws the above Invalid class loader hierarchy. > > > > > > The full verbose dump of tomcat shows that it's pulling LogFactory from > the Jetspeed jar, but then goes on to try to pull the Log4JLogger from > my portlet jar. It seems that using the Jetspeed services (in this case > PageManager) complicates the classpath of the portlet. > > > > Any suggestions would be helpful. > > > > David Just l Software Engineer l Vision Solutions l +1 (507) 529-5939 l [email protected] > The contents of this e-mail (and any attachments) are privileged and confidential. Unauthorized use is strictly prohibited. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
