All changes are in the trunk (0.3-INCUBATING-SNAPSHOT) and only there. You have rebuild OpenCMIS from the sources in order to use it.
It's not very convenient, I know... @all: How big is the interest to support CXF? The implementation is basically done, but setting up the build environment with all the dependencies and RI/CXF collisions could become a nightmare. We would also have to run the FIT tests twice. - Florian On 17/01/2011 15:40, [email protected] wrote: > Florian, > > I saw you made several changes to the opencmis-client-bindings classes. > Can you confirm I have to use this with the trunk version > (0.3-INCUBATING-SNAPSHOT) ? Do I have to rebuild openCMIS from sources > or will it be generated tomorrow on the snapshot repository ? > > thank you > > > > -----Florian Müller <[email protected]> a écrit : ----- > > A : [email protected] > De : Florian Müller <[email protected]> > Date : 17/01/2011 16:08 > cc: [email protected] > Objet : Re: [OpenCMIS] Incompatibility with CXF > > There seems to be no reasonable way to make that work with class > loader magic. > > So, I added a class that makes the OpenCMIS client work with CXF. I > ran a few smoke tests and it seems to work but consider it untested. > You also have to build the class yourself as we don't have CXF in > our build environment. > > > Here are the details: > > - The following directory contains now a file "PortProvider.java-cxf": > > /chemistry-opencmis-client/chemistry-opencmis-client-bindings/src/main/java/org/apache/chemistry/opencmis/client/bindings/spi/webservices > > - Get the file, rename it to "PortProvider.java" and compile it. > You'll need the OpenCMIS jars and CXF jars in the classpath. > > - When you run your application, make sure that the new class will > be found in the classpath before the OpenCMIS jars. > Or, replace the class in the chemistry-opencmis-client-bindings jar. > > > Florian > > > On 17/01/2011 13:21, [email protected] wrote: > > Indeed it may happen if there are any other explicit references to > > jax-ws classes. > > > > > > > > -----Florian Müller <[email protected]> a écrit : ----- > > > > A : [email protected], [email protected] > > De : Florian Müller <[email protected]> > > Date : 17/01/2011 12:39 > > Objet : Re: [OpenCMIS] Incompatibility with CXF > > > > That's an interesting approach. I'll give it a try. > > But I assume it will only defer the problem. I guess we will see > > other ClassCastException later. > > > > - Florian > > > > > > On 17/01/2011 11:38, [email protected] wrote: > > > Maybe somthing like this would do the trick : > > > > > > > > > ClassLoader cl = new URLClassLoader(new URL[0], > > > Thread.currentThread().getContextClassLoader()) { > > > public InputStream getResourceAsStream(String s) { > > > if > > > > > > > ("*META*-*INF*/*services*/*javax*.*xml*.*ws*.*spi*.*Provider*".equals("s")) > > > > > { > > > //return IS to com.sun.xml.ws.spi.ProviderImpl > > > } > > > return super.getResourceAsStream(s); > > > } > > > public URL getResource(String s) { > > > if > > > > > > > ("*META*-*INF*/*services*/*javax*.*xml*.*ws*.*spi*.*Provider*".equals("s")) > > > > > { > > > //return URL to com.sun.xml.ws.spi.ProviderImpl > > > } > > > return super.getResource(s); > > > } > > > }; > > > > > > //replace classloader > > > Thread.currentThread().setContextClassLoader(cl); > > > > > > // initialize openCMIS Services > > > [...] > > > > > > //restore default classloader > > > Thread.currentThread().setContextClassLoader(cl.getParent()); > > > > > > > > > > > > > > > Romain WILBERT > > > Ingénieur développement > > > AKKA Informatique & Systèmes > > > > > > -----Florian Müller <[email protected]> a écrit : ----- > > > > > > A : [email protected], [email protected] > > > De : Florian Müller <[email protected]> > > > Date : 17/01/2011 11:48 > > > Objet : Re: [OpenCMIS] Incompatibility with CXF > > > > > > Hi Romain, > > > > > > It is possible to force the use of com.sun.xml.ws.spi.ProviderImpl > > > by setting this system property: > > > javax.xml.ws.spi.Provider = com.sun.xml.ws.spi.ProviderImpl > > > > > > But that would probably interfere with your CXF Web Services. It's > > > not possible to use both with the same class loader. > > > > > > I'll try to add some class loader magic to OpenCMIS, but I can't > > > promise that this will work eventually. > > > > > > > > > - Florian > > > > > > > > > On 14/01/2011 16:27, [email protected] wrote: > > > > Hi ! > > > > > > > > Same problem as Erwan (apache CXF cohabitation...) => > > > > > > > (http://mail-archives.apache.org/mod_mbox/incubator-chemistry-dev/201101.mbox/browser) > > > > > > > > Since my project exposes CXF WebServices, I have an error while > > > initializing OpenCMIS WebService client : > > > > > > > > > > > > > > org.apache.chemistry.opencmis.commons.exceptions.CmisConnectionException: > > > Cannot initalize Web Services port object: $Proxy340 cannot be cast > > > to com.sun.xml.ws.developer.WSBindingProvider > > > > at > > > > > > > org.apache.chemistry.opencmis.client.bindings.spi.webservices.PortProvider.createPortObject(PortProvider.java:325) > > > > > > > > This happens because the first found provider on classloader is > > > org.apache.cxf.jaxws22.spi.ProviderImpl (cxf-rt-frontend-jaxws.jar > > > precedes jaxws-rt in classloader). My Proxy is a > > > org.apache.cxf.jaxws.JaxWsClientProxy, which causes the > > > ClassCastException. > > > > > > > > > > > > Any workaround for this ? Why don't you force the use of > > > com.sun.xml.ws.spi.ProviderImpl from jaxws-rt as it is anyway a > > > Maven dependency of opencmis-client ? > > > > > > > > Thanks. > > > > > > > > Romain WILBERT > > > > Ingénieur développement > > > > AKKA Informatique& Systèmes > > > > > > > > > > > > > > > > > > > > > > > > > >
