Hi Mark,
Using the chemistry-opencmis-client-binding-websphere-0.8.0.jar should
solve your problem. It cuts the dependency to the Sun JAX-WS
implementation, which can cause trouble even if you don't use the Web
Services binding.
The default bindings jar contains a configuration that forces JAX-WS to
use the Sun JAX-WS implementation. Depending on the classloader in the
application server that can have side effects for other web services
clients in the same application. In your case it seems JAX-WS finds the
Sun implementation that is part of the JRE. This is base on the RI 2.2
while OpenCMIS provides classes for the RI 2.1 and there seems to be a
compatibility issue.
The WebSphere bindings jar covers all CMIS bindings. You can use it even
if you are using the AtomPub or the Browser binding.
Florian
Hello
Please pardon the long post but I want to be clear in the description.
I am trying to chase down an issue we are seeing that "appears" to be
occurring based on the *order *of web service calls involving OpenCMIS
(0.8.0) RELEASE in a Websphere environment. We have a web application that
is deployed where we package the needed CMIS client-side JARs into
/WEB-INF/lib of the WAR:
chemistry-opencmis-client-api-0.8.0.jar
*chemistry-opencmis-client-bindings-0.8.0.jar*
chemistry-opencmis-client-impl-0.8.0.jar
chemistry-opencmis-commons-api-0.8.0.jar
chemistry-opencmis-commons-impl-0.8.0.jar
slf4j-api-1.6.x.jar
The application runs under Websphere 7, deploys and has worked perfectly
where we are able to make all the necessary calls to an Alfresco Community
4.2.b server. So far so good.
Also, we use only the AtomPub binding and do NOT make the calls using the
WSDL (JAX-WS) bindings approach.
Because of that we are *not including* the set of "dependency" JARs from
the JAX-WS RI (jaxws-api, jaxb-api, jaxws-rt, etc)...also more on this below
When setting up the client, we use this parameter when setting up and this
works just fine:
----
----
parameters.put(SessionParameter.BINDING_TYPE,
BindingType.ATOMPUB.value());
parameters.put(SessionParameter.ATOMPUB_URL, cmisServerAtomURL);
}
repositories = new ArrayList<Repository>();
repositories = this.sessionFactory.getRepositories(parameters);
We are able to get the Session, make all the required calls, and all seems
fine.
*HOWEVER, here is where we see a problem:*
- We *also *have our *own *JAX-WS client JAR for other web services
(non-CMIS) within our environment as well.
- The client artifacts for these are generated with JAX-WS RI 2.2 tools
with Ant ... but they *run from within the same web app where we make
CMIS calls deployed on WAS 7.0.0.13 / JDK 6* so we are dependent on the
WAS 7 runtime jars (we know that attempting to include JAX-WS RI - related
JAR files end up conflicting with those provided by the built-in Axis2
stack provided by WAS7). As stated before, we don't include the JAX-WS
dependency JAR files
- This JAX-WS client JAR that we create, is also placed in the
/WEB-INF/lib of the same WAR
1. If we use our JAX-WS client to call our services - that call works
2. If we then call the CMIS services (based on the AtomPub binding), *that
also works*
3. If we then use our JAX-WS client to AGAIN call our services - that
call now FAILS with an exception relating to the SOAP headers we attempt to
inject on our JAX-WS client calls
*<brief part of stack trace>*
org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to
insert a node where it is
not permitted. - WebServiceException caught:
javax.xml.ws.WebServiceException: org.w3c.dom.DOMException:
HIERARCHY_REQUEST_ERR: An attempt was made to insert a node where it is not
permitted.
at
com.sun.xml.internal.ws.handler.ClientSOAPHandlerTube.callHandlersOnRequest(ClientSOAPHandlerTube.java:147)
at ....
So we switch the call order above...to see what happens...
1. If we call the CMIS services (based on the AtomPub binding), that
call works
2. If we then use our JAX-WS client to call our services - that call now
FAILS with that same exception relating to the SOAP headers we attempt to
inject on our JAX-WS client calls
It *appears *that AFTER a call is made using the CMIS client JARs, any
attempt to call our JAX-WS web services via our own JAX-WS client will not
work.
After digging around some, I found the special Websphere binding JAR and
the text file describing the following:
This artifact is an OpenCMIS Client Bindings Jar that only works on
IBM WebSphere 7.0.0.5 and later. It takes advantage of the JAX-WS
implementation
provided by WebSphere, reduces OpenCMIS’ dependencies and avoids potential
conflicts with the Suns JAX-WS implementation that is usually required
for OpenCMIS.
In order to use the OpenCMIS client library in a web application on
WebSphere,
place the following jars into /WEB-INF/lib :
chemistry-opencmis-client-api-<version>.jar
chemistry-opencmis-client-impl-<version>.jar
*chemistry-opencmis-client-binding-websphere-<version>.jar*
chemistry-opencmis-commons-api-<version>.jar
chemistry-opencmis-commons-impl-<version>.jar
slf4j-api-1.6.x.jar
Other dependencies mentioned in other parts of the OpenCMIS documentation
are
not required. Make sure that the default OpenCMIS Client Bindings Jar
is not present.
I am now guessing, because we have NOT used this special *Websphere
version*for the client binding, this MAY be the problem..
Perhaps I mistakenly thought this was only needed if one was using the WSDL
binding option and making JAX-WS calls. However, when I open the
chemistry-opencmis-client-binding-websphere-0.8.0.jar , I do see classes
related to AtomPub as well.
Am I understanding this correctly?
Thanks
Mark
