chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Streit <mcs...@gmail.com>
Subject question on Chemistry client API (0.8.0 release) - usage from Websphere 7
Date Sat, 19 Jan 2013 04:21:04 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message