I tried your workaround, my project still ends up with the commons-logging jar file in the output, but deleting it manually resolves the issue.
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. -----Original Message----- From: Ate Douma [mailto:[email protected]] Sent: Wednesday, September 09, 2009 4:56 PM To: Jetspeed Users List Subject: Re: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log Ate Douma wrote: > David Just wrote: >> 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. > > Right, that is the problem. > > Seems like we let a transitive commons-logging dependency slip through > after all :( > Strange thing is this doesn't happen/show up within the jetspeed project > itself, e.g. in the jetspeed/applications/jetspeed-demo module. > However, I just now found out it *does* happen with custom projects > generated with the jetspeed maven archetype... > And, even more strange, in both cases only the jetspeed-dependencies:pom > is pulled in. > My guess is that in the jetspeed project we somehow must have defined an > additional commons-logging exclusion on ddlutils higher up in the > project tree, which is "missing" in a custom portal project. > > Sigh, I will look further into this tomorrow and get it fixed ASAP on > trunk. Right, turns out *I* myself already fixed that on trunk some weeks ago ... Shows how selective my memory works with regards to Maven quirks ;) So, for the next release this issue is already solved, however for custom portal projects generated with the jetspeed 2.2.0 maven archetype the below fix remains required and needs to be manually applied I'm afraid. Regards, Ate > For your own project, you probably best fix this manually by explicitly > excluding commons-logging for the jetspeed-dependencies dependency on > your ui-portal war module: > > <dependency> > <groupId>org.apache.portals.jetspeed-2</groupId> > <artifactId>jetspeed-dependencies</artifactId> > <version>${org.apache.portals.jetspeed.version}</version> > <type>pom</type> > <exclusions> > <exclusion> > <groupId>commons-logging</groupId> > <artifactId>commons-logging</artifactId> > </exclusion> > </exclusions> > </dependency> > > Regards, > > Ate > >> >> -----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] >> > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
