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.
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]
