Hi Lars-Fredrik I responded to a similar question some time ago as well. Here is the text of that one below the line.
* Note this was addressing someone's question where the "client" proxy end of the interaction was failing due to interference from Axis2 (IBM's choice of JAX-WS stacks, though I'm not sure why). I believe the same principles would apply either way. ==================================================================== I know that we have used client proxy code generated using Metro tooling (JAX-WS RI 2.1, wsimport) ... in the past and run on WAS7 servers... A couple of things I can recall from that "experience" -- and I think the *same pattern would apply using the CXF stack and tools)* 1) this article might be helpful http://www.jroller.com/gmazza/entry/web_service_ear_tutorial - from Glen Mazza (does discuss more from the server side of things but much of it applies when you're dealing with WAS) 2) this one may help as well: http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_thirdparty.html And, here is the V8 version: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_thirdparty.html 3) classloader policy MUST be *PARENT_LAST* for the deployed WAR file (which can contain your JAX-WS client proxy artifacts often packaged as a JAR file) in the /WEB-INF/lib of the deployed WAR file. This assumes the WAR file would represent your web application that could be making client calls to web service endpoints)... 4) in WAS7, we also had to insure "classloader per application" (per WAR) and NOT "single classloader" IBM WAS7 chose to use Axis2, for reasons, which even today, still puzzle me. When stacks like CXF and Metro are are better (CXF being the more robust of the 2 IMO), the Axis2 stuff seems very dated. I believe this MAY have changed in WAS 8 but I am not certain as we are not using WAS 8 at the moment... replacing many environments with Tomcat 7. I did come across this which "implies" they may still have their customized axis2 code still being used in v8: http://stackoverflow.com/questions/11398724/websphere-8-jax-ws-client-for-axis2-ws HTH Mark On Mon, Sep 15, 2014 at 4:43 AM, Andrei Shakirin <[email protected]> wrote: > Hi, > > This looks like class loader order issue. > You can try to change class loading to local class loader first (parent > last) at the module level. > > These links can be helpful: > > http://www.colleoni.info/wp/en/2013/04/howto-cxf-jax-ws-web-services-su-websphere-as-7/ > > http://stackoverflow.com/questions/5971536/cxf-on-websphere-6-1-class-loading-problem > > Regards, > Andrei. > > > -----Original Message----- > > From: Lars-Fredrik Smedberg [mailto:[email protected]] > > Sent: Donnerstag, 11. September 2014 09:42 > > To: [email protected] > > Subject: CXF and WebSphere 8.5.5 > > > > Hi! > > > > When we in development run WebSphere 8.5.5. Liberty Profile things works > > fine and from my understanding Liberty Profile uses CXF 2.6.x. > > > > However when we deploy the code in the test environments which runs the > full > > WebSphere 8.5.5 (not Liberty Profile) we run into bugs related to > > @WebMethod or @XmlElement and its name attribute. The stack trace > > indicates that WebSphere full version uses Axis2 and not CXF. > > > > Is there a way of changing to CXF without having to bundle CXF in the > deployed > > EAR, change class loading order etc as suggested in some articles? > > > > Regards > > Lars-Fredrik > > > > -- > > Med vänlig hälsning / Best regards > > > > Lars-Fredrik Smedberg > > > > STATEMENT OF CONFIDENTIALITY: > > The information contained in this electronic message and any attachments > to > > this message are intended for the exclusive use of the > > address(es) and may contain confidential or privileged information. If > you are > > not the intended recipient, please notify Lars-Fredrik Smedberg > immediately at > > [email protected], and destroy all copies of this message and any > > attachments. >
