David Just wrote:
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.
Did you execute mvn dependency:tree -Dincludes=commons-logging again after my
workaround?
Sometimes you have to do this repeatedly as Maven might now pickup a transitive
dependency on commons-logging from another dependency.
In my custom portal project the workaround was the only change needed, but your
project can be different, have more/additional dependencies.
Ate
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
