Re: CXF 2.2 and class-loading issues
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 @@ 3.1.2 10.5.3.0_1 - 2.1.4 + 2.2.6 1.5 1.2.8 2.5.6 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 @@ wss4j jar + + org.bouncycastle + bcprov-jdk15 + jar + 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
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 @@ 3.1.2 10.5.3.0_1 - 2.1.4 + 2.2.6 1.5 1.2.8 2.5.6 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 @@ wss4j jar + + org.bouncycastle + bcprov-jdk15 + jar + 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
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: org.springframework org.apache.cxf 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: org.springframework org.apache.cxf -> org.apache.geronimo.cxf 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?
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: org.springframework org.apache.cxf 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: org.springframework org.apache.cxf -> org.apache.geronimo.cxf 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: Container-managed JPA in pure WAR with JNDI
Hello David, Thanks for helping out. Following yout e-mail: 1) I've fixed the problem by using "SystemDatasource" (not SystemDatabse) as the name. 2) I don't really care whether Geronimo uses JNDI or not internally. I need to register the JPA persistence context in my web application's JNDI context, as I am using Spring which expects to be able to look it up via JNDI (using if you're familiar with Spring). So I need the reference in web.xml for my own purposes. Anyway, it works now so this has been resolved. 3) I don't really intend to use Derby; I was just taking things step-by-step. Having said that, how do I define my own datasource in Geronimo? For example, in JBoss you use a "somename-ds.xml" file to register a datasource. On 12/2/2010 8:20 μμ, David Jencks wrote: Geronimo doesn't use jndi for the datasources in persistence.xml. You don't need to configure resource-refs for the datasources. You do need to make sure they are in ancestor plugins to the app and that you use the name from the datasource configuration. In this case I think that would be SystemDatabase In my experience, at least with derby, you need both jta and non-jta datasource. I guess if you aren't using jta transactions at all you might be able to use just a non-jta-data-source, but I haven't tried this. thanks david jencks On Feb 12, 2010, at 6:53 AM, Alexandros Karypidis wrote: Hello, My scenario is this: I have a library with entities (as in @Entity objects) containing my domain model. I want to declare a container-managed persistence unit in a standalone WAR (not EAR), using that library (the persistence.xml must NOT be in the library, but the WAR). So, I proceed as follows (this is valid as far as I know, base on J2EE5 specs): 1) I have declared a data source in geronimo-web.xml and web.xml (see below for file contents). 2) I put my library (as a jar) in my WAR's WEB-INF/lib and added a WEB-INF/classes/META-INF/persistence.xml in the WAR (see below for file contents). Deployment after performing step (1) worked and I could see the data source registered in the console. Deployment after performing step (2) fails; from what I understand from the error (see below), geronimo claims the data-source from step (1) does not exist. I assume that geronimo tries to create the persistence context prior to registering the data source? (i.e. it processes persistence.xml prior to apply the configuration from web.xml and geronimo-web.xml). What do I need to configure this properly. My deployment descriptors and the error trace follow: persistence.xml - http://java.sun.com/xml/ns/persistence"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"; version="1.0"> jdbc/AppDataSource app-entities.jar web.xml - http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd"; version="2.4"> App jdbc/AppDataSource javax.sql.DataSource Container Shareable geronimo-web.xml - http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1"; xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2"; xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0"; xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2";> app app-frontend 0.0.1 car org.apache.geronimo.configs system-database /app jdbc/AppDataSource SystemDatasource __ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://mail.yahoo.gr
Container-managed JPA in pure WAR with JNDI
Hello, My scenario is this: I have a library with entities (as in @Entity objects) containing my domain model. I want to declare a container-managed persistence unit in a standalone WAR (not EAR), using that library (the persistence.xml must NOT be in the library, but the WAR). So, I proceed as follows (this is valid as far as I know, base on J2EE5 specs): 1) I have declared a data source in geronimo-web.xml and web.xml (see below for file contents). 2) I put my library (as a jar) in my WAR's WEB-INF/lib and added a WEB-INF/classes/META-INF/persistence.xml in the WAR (see below for file contents). Deployment after performing step (1) worked and I could see the data source registered in the console. Deployment after performing step (2) fails; from what I understand from the error (see below), geronimo claims the data-source from step (1) does not exist. I assume that geronimo tries to create the persistence context prior to registering the data source? (i.e. it processes persistence.xml prior to apply the configuration from web.xml and geronimo-web.xml). What do I need to configure this properly. My deployment descriptors and the error trace follow: persistence.xml - http://java.sun.com/xml/ns/persistence"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"; version="1.0"> jdbc/AppDataSource app-entities.jar web.xml - http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd"; version="2.4"> App jdbc/AppDataSource javax.sql.DataSource Container Shareable geronimo-web.xml - http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1"; xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2"; xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0"; xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2";> app app-frontend 0.0.1 car org.apache.geronimo.configs system-database /app jdbc/AppDataSource SystemDatasource __ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://mail.yahoo.gr
