You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Alexandros Karypidis <ak...@yahoo.gr> on 2010/02/20 18:24:08 UTC
CXF 2.2 and class-loading issues
Hello,
I need to use CXF 2.2 in my WAR. I have therefore included it in my
WEB-INF/lib and hidden the Geronimo 2.2 classes (it embeds CXF 2.1.4)
using the following declarations in geronimo-web.xml:
<hidden-classes>
<filter>org.springframework</sys:filter>
<filter>org.apache.cxf</sys:filter>
</hidden-classes>
When loading the CXFServlet during my war's startup, a CXF extension is
activated (META-INF/cxf/cxf-extension-geronimo.xml) that probably uses
classes loaded from the Geronimo-included CXF (2.1.4) causing class
definition mismatch (Cannot convert value of type
[org.apache.cxf.resource.ClasspathResolver] to required type
[org.apache.cxf.resource.ResourceResolver]).
The relevant stack trace is:
---------------------------------------------------------------------------------
2010-02-20 19:08:05,050 WARN [SpringBusFactory] Initial attempt to
crate application context was unsuccessful.
org.springframework.beans.factory.UnsatisfiedDependencyException: Error
creating bean with name 'org.apache.cxf.resource.ResourceManager'
defined in class path resource
[META-INF/cxf/cxf-extension-geronimo.xml]: Unsatisfied dependency
expressed through constructor argument with index 0 of type
[java.util.List]: Could not convert constructor argument value of type
[java.util.ArrayList] to required type [java.util.List]: Failed to
convert value of type [java.util.ArrayList] to required type
[java.util.List]; nested exception is
java.lang.IllegalArgumentException: Cannot convert value of type
[org.apache.cxf.resource.ClasspathResolver] to required type
[org.apache.cxf.resource.ResourceResolver]: no matching editors or
conversion strategy found
...
Caused by:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error
creating bean with name 'org.apache.cxf.resource.ResourceManager'
defined in class path resource
[META-INF/cxf/cxf-extension-geronimo.xml]: Unsatisfied dependency
expressed through constructor argument with index 0 of type
[java.util.List]: Could not convert constructor argument value of type
[java.util.ArrayList] to required type [java.util.List]: Failed to
convert value of type [java.util.ArrayList] to required type
[java.util.List]; nested exception is
java.lang.IllegalArgumentException: Cannot convert value of type
[org.apache.cxf.resource.ClasspathResolver] to required type
[org.apache.cxf.resource.ResourceResolver]: no matching editors or
conversion strategy found
at
org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:565)
....
---------------------------------------------------------------------------------
Now, since "cxf-extension-geronimo.xml" comes from a Geronimo library
(http://repo2.maven.org/maven2/org/apache/geronimo/modules/geronimo-cxf/2.2/geronimo-cxf-2.2.pom),
how can I prevent the CXF embedded inside my WAR to ignore it? It's not
a package, but rather a classpath resource (it's in META-INF/cxf) so
there's no point in "hiding" a package. For example, I tried the
following, which simply led to a ClassNotFoundException:
<hidden-classes>
<filter>org.springframework</sys:filter>
<filter>org.apache.cxf</sys:filter>
-> <filter>org.apache.geronimo.cxf</sys:filter>
</hidden-classes>
This is normal, as CXF can still see the
META-INF/cxf/cxf-extension-geronimo.xml resource in its classpath and
still tries to load the extension, only this time it's hidden and
results in the ClassNotFoundException...
Is there any way to get around this?
Re: CXF 2.2 and class-loading issues
Posted by Alexandros Karypidis <ak...@yahoo.gr>.
http://issues.apache.org/jira/browse/GERONIMO-5153
On 21/2/2010 5:51 μμ, Alexandros Karypidis wrote:
> Hello,
>
> It appears that going to CXF 2.2.6 may actually be quite painless.
> Compilation succeeded immediately, all unit tests succeeded and the
> server started with no problems. So far I've deployed a couple of
> things and have run into no trouble at all.
>
> All I changed was the top-level "cxfVersion" property in pom.xml (and
> deleted a dependencies.xml which was re-generated). So I think the
> maintainers should definitely consider moving the trunk to CXF 2.2.6
> immediately and even consider it for the 2.2-branch. I'll open a JIRA
> for this.
>
> C:\g22>svn diff pom.xml plugins\cxf\cxf\src\main\history\dependencies.xml
> Index: pom.xml
> ===================================================================
> --- pom.xml (revision 912260)
> +++ pom.xml (working copy)
> @@ -67,7 +67,7 @@
>
> <openejbVersion>3.1.2</openejbVersion>
> <derbyVersion>10.5.3.0_1</derbyVersion>
> - <cxfVersion>2.1.4</cxfVersion>
> + <cxfVersion>2.2.6</cxfVersion>
> <axis2Version>1.5</axis2Version>
> <axiomVersion>1.2.8</axiomVersion>
> <springVersion>2.5.6</springVersion>
> Index: plugins/cxf/cxf/src/main/history/dependencies.xml
> ===================================================================
> --- plugins/cxf/cxf/src/main/history/dependencies.xml (revision 912260)
> +++ plugins/cxf/cxf/src/main/history/dependencies.xml (working copy)
> @@ -111,4 +111,9 @@
> <artifactId>wss4j</artifactId>
> <type>jar</type>
> </dependency>
> + <dependency>
> + <groupId>org.bouncycastle</groupId>
> + <artifactId>bcprov-jdk15</artifactId>
> + <type>jar</type>
> + </dependency>
> </plugin-artifact>On 20/2/2010 10:59 μμ, Kevan Miller wrote:
>> On Feb 20, 2010, at 3:33 PM, Alexandros Karypidis wrote:
>>
>>> I've put the CXF 2.2.6 jars in repository/org/apache/cxf/xxx/2.2.6,
>>> alongside the 2.1.4 ones.
>>>
>>> Could you please give an example / point me to documentation for
>>> "artifact-alias entries"?
>> Have a look at var/config/artifact_aliases.properties
>>
>> It will only contain alias entries for car artifacts, but you can
>> also alias jar artifacts. Something like the following, I think:
>>
>> org.apache.cxf/xxx//jar=org.apache.cxf/xxx/2.2.6/jar
>>
>> If I had to guess, I'd guess that aliasing won't work. But I've been
>> wrong before...
>>
>>> Meanwhile, I've checked out the trunk and am waiting for an "mvn
>>> install" to complete. I may very well do the upgrade. CXF 2.1 will
>>> no longer be developed except for significant issues (2.1.9 was the
>>> end of the line) and 2.2.6 is being adverized as the most stable
>>> release ever (http://www.dankulp.com/blog/?p=182). So it'd be nice
>>> if Geronimo 2.3 used it (or even 2.2.1).
>> That would be great.
>>
>> However, branches/2.2
>> (https://svn.apache.org/repos/asf/geronimo/server/branches/2.2) is
>> your best bet for making this change. trunk is working on EE6 and
>> OSGi. It's not going to be very stable for your purposes.
>>
>> You'll need to bump cxfVersion in pom.xml. FYI, you'll find most/all
>> of the integration code in plugins/cxf.
>>
>> --kevan
Re: CXF 2.2 and class-loading issues
Posted by Alexandros Karypidis <ak...@yahoo.gr>.
Hello,
It appears that going to CXF 2.2.6 may actually be quite painless.
Compilation succeeded immediately, all unit tests succeeded and the
server started with no problems. So far I've deployed a couple of things
and have run into no trouble at all.
All I changed was the top-level "cxfVersion" property in pom.xml (and
deleted a dependencies.xml which was re-generated). So I think the
maintainers should definitely consider moving the trunk to CXF 2.2.6
immediately and even consider it for the 2.2-branch. I'll open a JIRA
for this.
C:\g22>svn diff pom.xml plugins\cxf\cxf\src\main\history\dependencies.xml
Index: pom.xml
===================================================================
--- pom.xml (revision 912260)
+++ pom.xml (working copy)
@@ -67,7 +67,7 @@
<openejbVersion>3.1.2</openejbVersion>
<derbyVersion>10.5.3.0_1</derbyVersion>
- <cxfVersion>2.1.4</cxfVersion>
+ <cxfVersion>2.2.6</cxfVersion>
<axis2Version>1.5</axis2Version>
<axiomVersion>1.2.8</axiomVersion>
<springVersion>2.5.6</springVersion>
Index: plugins/cxf/cxf/src/main/history/dependencies.xml
===================================================================
--- plugins/cxf/cxf/src/main/history/dependencies.xml (revision 912260)
+++ plugins/cxf/cxf/src/main/history/dependencies.xml (working copy)
@@ -111,4 +111,9 @@
<artifactId>wss4j</artifactId>
<type>jar</type>
</dependency>
+ <dependency>
+ <groupId>org.bouncycastle</groupId>
+ <artifactId>bcprov-jdk15</artifactId>
+ <type>jar</type>
+ </dependency>
</plugin-artifact>On 20/2/2010 10:59 μμ, Kevan Miller wrote:
> On Feb 20, 2010, at 3:33 PM, Alexandros Karypidis wrote:
>
>
>> I've put the CXF 2.2.6 jars in repository/org/apache/cxf/xxx/2.2.6, alongside the 2.1.4 ones.
>>
>> Could you please give an example / point me to documentation for "artifact-alias entries"?
>>
> Have a look at var/config/artifact_aliases.properties
>
> It will only contain alias entries for car artifacts, but you can also alias jar artifacts. Something like the following, I think:
>
> org.apache.cxf/xxx//jar=org.apache.cxf/xxx/2.2.6/jar
>
> If I had to guess, I'd guess that aliasing won't work. But I've been wrong before...
>
>
>> Meanwhile, I've checked out the trunk and am waiting for an "mvn install" to complete. I may very well do the upgrade. CXF 2.1 will no longer be developed except for significant issues (2.1.9 was the end of the line) and 2.2.6 is being adverized as the most stable release ever (http://www.dankulp.com/blog/?p=182). So it'd be nice if Geronimo 2.3 used it (or even 2.2.1).
>>
> That would be great.
>
> However, branches/2.2 (https://svn.apache.org/repos/asf/geronimo/server/branches/2.2) is your best bet for making this change. trunk is working on EE6 and OSGi. It's not going to be very stable for your purposes.
>
> You'll need to bump cxfVersion in pom.xml. FYI, you'll find most/all of the integration code in plugins/cxf.
>
> --kevan
>
Re: CXF 2.2 and class-loading issues
Posted by Kevan Miller <ke...@gmail.com>.
On Feb 20, 2010, at 3:33 PM, Alexandros Karypidis wrote:
> I've put the CXF 2.2.6 jars in repository/org/apache/cxf/xxx/2.2.6, alongside the 2.1.4 ones.
>
> Could you please give an example / point me to documentation for "artifact-alias entries"?
Have a look at var/config/artifact_aliases.properties
It will only contain alias entries for car artifacts, but you can also alias jar artifacts. Something like the following, I think:
org.apache.cxf/xxx//jar=org.apache.cxf/xxx/2.2.6/jar
If I had to guess, I'd guess that aliasing won't work. But I've been wrong before...
>
> Meanwhile, I've checked out the trunk and am waiting for an "mvn install" to complete. I may very well do the upgrade. CXF 2.1 will no longer be developed except for significant issues (2.1.9 was the end of the line) and 2.2.6 is being adverized as the most stable release ever (http://www.dankulp.com/blog/?p=182). So it'd be nice if Geronimo 2.3 used it (or even 2.2.1).
That would be great.
However, branches/2.2 (https://svn.apache.org/repos/asf/geronimo/server/branches/2.2) is your best bet for making this change. trunk is working on EE6 and OSGi. It's not going to be very stable for your purposes.
You'll need to bump cxfVersion in pom.xml. FYI, you'll find most/all of the integration code in plugins/cxf.
--kevan
Re: CXF 2.2 and class-loading issues
Posted by Alexandros Karypidis <ak...@yahoo.gr>.
I've put the CXF 2.2.6 jars in repository/org/apache/cxf/xxx/2.2.6,
alongside the 2.1.4 ones.
Could you please give an example / point me to documentation for
"artifact-alias entries"?
Meanwhile, I've checked out the trunk and am waiting for an "mvn
install" to complete. I may very well do the upgrade. CXF 2.1 will no
longer be developed except for significant issues (2.1.9 was the end of
the line) and 2.2.6 is being adverized as the most stable release ever
(http://www.dankulp.com/blog/?p=182). So it'd be nice if Geronimo 2.3
used it (or even 2.2.1).
Could you point
On 20/2/2010 8:30 μμ, David Jencks wrote:
> I'm not a web services expert at all...
>
> If you put cxf jars in your app then you should not expect any
> container managed web services stuff to work at all and you should
> just turn off the cxf and cxf-deployer plugins in config.xml. If the
> classes aren't available in geronimo you shouldn't need to use the
> hidden-classes.
>
> Another approach that might possibly work if cxf 2.2 is sufficiently
> backwards compatible with 2.1.4 is to put the 2.2 cxf jars in the
> appropriate places in the geronimo repository and add artifact-alias
> entries for each one. It's possible that you'd then be able to run
> geronimo using 2.2.
>
> If this doesn't work.... you could revise the geronimo cxf integration
> to work with cxf 2.2 and give us a patch :-)
>
> hope this helps
> david jencks
>
> On Feb 20, 2010, at 9:24 AM, Alexandros Karypidis wrote:
>
>> Hello,
>>
>> I need to use CXF 2.2 in my WAR. I have therefore included it in my
>> WEB-INF/lib and hidden the Geronimo 2.2 classes (it embeds CXF 2.1.4)
>> using the following declarations in geronimo-web.xml:
>>
>> <hidden-classes>
>> <filter>org.springframework</sys:filter>
>> <filter>org.apache.cxf</sys:filter>
>> </hidden-classes>
>>
>> When loading the CXFServlet during my war's startup, a CXF extension
>> is activated (META-INF/cxf/cxf-extension-geronimo.xml) that probably
>> uses classes loaded from the Geronimo-included CXF (2.1.4) causing
>> class definition mismatch (Cannot convert value of type
>> [org.apache.cxf.resource.ClasspathResolver] to required type
>> [org.apache.cxf.resource.ResourceResolver]).
>>
>> The relevant stack trace is:
>>
>> ---------------------------------------------------------------------------------
>>
>> 2010-02-20 19:08:05,050 WARN [SpringBusFactory] Initial attempt to
>> crate application context was unsuccessful.
>> org.springframework.beans.factory.UnsatisfiedDependencyException:
>> Error creating bean with name
>> 'org.apache.cxf.resource.ResourceManager' defined in class path
>> resource [META-INF/cxf/cxf-extension-geronimo.xml]: Unsatisfied
>> dependency expressed through constructor argument with index 0 of
>> type [java.util.List]: Could not convert constructor argument value
>> of type [java.util.ArrayList] to required type [java.util.List]:
>> Failed to convert value of type [java.util.ArrayList] to required
>> type [java.util.List]; nested exception is
>> java.lang.IllegalArgumentException: Cannot convert value of type
>> [org.apache.cxf.resource.ClasspathResolver] to required type
>> [org.apache.cxf.resource.ResourceResolver]: no matching editors or
>> conversion strategy found
>> ...
>> Caused by:
>> org.springframework.beans.factory.UnsatisfiedDependencyException:
>> Error creating bean with name
>> 'org.apache.cxf.resource.ResourceManager' defined in class path
>> resource [META-INF/cxf/cxf-extension-geronimo.xml]: Unsatisfied
>> dependency expressed through constructor argument with index 0 of
>> type [java.util.List]: Could not convert constructor argument value
>> of type [java.util.ArrayList] to required type [java.util.List]:
>> Failed to convert value of type [java.util.ArrayList] to required
>> type [java.util.List]; nested exception is
>> java.lang.IllegalArgumentException: Cannot convert value of type
>> [org.apache.cxf.resource.ClasspathResolver] to required type
>> [org.apache.cxf.resource.ResourceResolver]: no matching editors or
>> conversion strategy found
>> at
>> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:565)
>>
>> ....
>>
>> ---------------------------------------------------------------------------------
>>
>>
>> Now, since "cxf-extension-geronimo.xml" comes from a Geronimo library
>> (http://repo2.maven.org/maven2/org/apache/geronimo/modules/geronimo-cxf/2.2/geronimo-cxf-2.2.pom),
>> how can I prevent the CXF embedded inside my WAR to ignore it? It's
>> not a package, but rather a classpath resource (it's in META-INF/cxf)
>> so there's no point in "hiding" a package. For example, I tried the
>> following, which simply led to a ClassNotFoundException:
>>
>> <hidden-classes>
>> <filter>org.springframework</sys:filter>
>> <filter>org.apache.cxf</sys:filter>
>> -> <filter>org.apache.geronimo.cxf</sys:filter>
>> </hidden-classes>
>>
>> This is normal, as CXF can still see the
>> META-INF/cxf/cxf-extension-geronimo.xml resource in its classpath and
>> still tries to load the extension, only this time it's hidden and
>> results in the ClassNotFoundException...
>>
>> Is there any way to get around this?
>>
Re: CXF 2.2 and class-loading issues
Posted by David Jencks <da...@yahoo.com>.
I'm not a web services expert at all...
If you put cxf jars in your app then you should not expect any
container managed web services stuff to work at all and you should
just turn off the cxf and cxf-deployer plugins in config.xml. If the
classes aren't available in geronimo you shouldn't need to use the
hidden-classes.
Another approach that might possibly work if cxf 2.2 is sufficiently
backwards compatible with 2.1.4 is to put the 2.2 cxf jars in the
appropriate places in the geronimo repository and add artifact-alias
entries for each one. It's possible that you'd then be able to run
geronimo using 2.2.
If this doesn't work.... you could revise the geronimo cxf integration
to work with cxf 2.2 and give us a patch :-)
hope this helps
david jencks
On Feb 20, 2010, at 9:24 AM, Alexandros Karypidis wrote:
> Hello,
>
> I need to use CXF 2.2 in my WAR. I have therefore included it in my
> WEB-INF/lib and hidden the Geronimo 2.2 classes (it embeds CXF
> 2.1.4) using the following declarations in geronimo-web.xml:
>
> <hidden-classes>
> <filter>org.springframework</sys:filter>
> <filter>org.apache.cxf</sys:filter>
> </hidden-classes>
>
> When loading the CXFServlet during my war's startup, a CXF extension
> is activated (META-INF/cxf/cxf-extension-geronimo.xml) that probably
> uses classes loaded from the Geronimo-included CXF (2.1.4) causing
> class definition mismatch (Cannot convert value of type
> [org.apache.cxf.resource.ClasspathResolver] to required type
> [org.apache.cxf.resource.ResourceResolver]).
>
> The relevant stack trace is:
>
> ---------------------------------------------------------------------------------
> 2010-02-20 19:08:05,050 WARN [SpringBusFactory] Initial attempt to
> crate application context was unsuccessful.
> org.springframework.beans.factory.UnsatisfiedDependencyException:
> Error creating bean with name
> 'org.apache.cxf.resource.ResourceManager' defined in class path
> resource [META-INF/cxf/cxf-extension-geronimo.xml]: Unsatisfied
> dependency expressed through constructor argument with index 0 of
> type [java.util.List]: Could not convert constructor argument value
> of type [java.util.ArrayList] to required type [java.util.List]:
> Failed to convert value of type [java.util.ArrayList] to required
> type [java.util.List]; nested exception is
> java.lang.IllegalArgumentException: Cannot convert value of type
> [org.apache.cxf.resource.ClasspathResolver] to required type
> [org.apache.cxf.resource.ResourceResolver]: no matching editors or
> conversion strategy found
> ...
> Caused by:
> org.springframework.beans.factory.UnsatisfiedDependencyException:
> Error creating bean with name
> 'org.apache.cxf.resource.ResourceManager' defined in class path
> resource [META-INF/cxf/cxf-extension-geronimo.xml]: Unsatisfied
> dependency expressed through constructor argument with index 0 of
> type [java.util.List]: Could not convert constructor argument value
> of type [java.util.ArrayList] to required type [java.util.List]:
> Failed to convert value of type [java.util.ArrayList] to required
> type [java.util.List]; nested exception is
> java.lang.IllegalArgumentException: Cannot convert value of type
> [org.apache.cxf.resource.ClasspathResolver] to required type
> [org.apache.cxf.resource.ResourceResolver]: no matching editors or
> conversion strategy found
> at
> org
> .springframework
> .beans
> .factory
> .support
> .ConstructorResolver.createArgumentArray(ConstructorResolver.java:565)
> ....
>
> ---------------------------------------------------------------------------------
>
> Now, since "cxf-extension-geronimo.xml" comes from a Geronimo
> library (http://repo2.maven.org/maven2/org/apache/geronimo/modules/geronimo-cxf/2.2/geronimo-cxf-2.2.pom
> ), how can I prevent the CXF embedded inside my WAR to ignore it?
> It's not a package, but rather a classpath resource (it's in META-
> INF/cxf) so there's no point in "hiding" a package. For example, I
> tried the following, which simply led to a ClassNotFoundException:
>
> <hidden-classes>
> <filter>org.springframework</sys:filter>
> <filter>org.apache.cxf</sys:filter>
> -> <filter>org.apache.geronimo.cxf</sys:filter>
> </hidden-classes>
>
> This is normal, as CXF can still see the META-INF/cxf/cxf-extension-
> geronimo.xml resource in its classpath and still tries to load the
> extension, only this time it's hidden and results in the
> ClassNotFoundException...
>
> Is there any way to get around this?
>