CXF and WebSphere 8.5.5

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-----
Sent: Donnerstag, 11. September 2014 09:42
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
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
attachments

Mark Streit

2014-09-15 11:46:07 UTC

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

Post by Andrei Shakirin
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.
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.

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
The information contained in this electronic message and any attachments

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

attachments.

Lars-Fredrik Smedberg

2014-09-15 13:05:35 UTC

@Mark

Thanks for your email. I will look through all articles/hints you posted.

We are using WebSphere 8.5.5.3 in some environments and we also see Axis2
related things (e.g. when looking at Stacktraces etc) so it still seems to
be in there :)

Regards
LF

Post by Mark Streit
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)
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_thirdparty.html
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
http://stackoverflow.com/questions/11398724/websphere-8-jax-ws-client-for-axis2-ws
HTH
Mark

Post by Andrei Shakirin
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.

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

Post by Andrei Shakirin
Regards,
Andrei.

-----Original Message-----
Sent: Donnerstag, 11. September 2014 09:42
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

deployed

attachments

Post by Andrei Shakirin
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

attachments.

--
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 itsmeden-***@public.gmane.org, and destroy all copies of this
message and any attachments.

Mark Streit

2014-09-15 13:15:37 UTC

Just an FYI. The Mazza article may have moved recently to here.
https://web-gmazza.rhcloud.com/blog/entry/web-service-ear-tutorial

Post by Lars-Fredrik Smedberg
@Mark
Thanks for your email. I will look through all articles/hints you posted.
We are using WebSphere 8.5.5.3 in some environments and we also see Axis2
related things (e.g. when looking at Stacktraces etc) so it still seems to
be in there :)
Regards
LF

Post by Mark Streit
Hi Lars-Fredrik
I responded to a similar question some time ago as well. Here is the

text

Post by Mark Streit
of that one below the line.
* Note this was addressing someone's question where the "client" proxy

end

Post by Mark Streit
of the interaction was failing due to interference from Axis2 (IBM's

choice

Post by Mark Streit
of JAX-WS stacks, though I'm not sure why). I believe the same

principles

Post by Mark Streit
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

Post by Mark Streit
Mazza (does discuss more from the server side of things but much of it
applies when you're dealing with WAS)

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_thirdparty.html
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_thirdparty.html

Post by Mark Streit
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

Post by Mark Streit
have changed in WAS 8 but I am not certain as we are not using WAS 8 at

the

Post by Mark Streit
moment... replacing many environments with Tomcat 7.
I did come across this which "implies" they may still have their

customized
http://stackoverflow.com/questions/11398724/websphere-8-jax-ws-client-for-axis2-ws

Post by Mark Streit
HTH
Mark

<javascript:;>>

Post by Andrei Shakirin
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.

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

Post by Andrei Shakirin
Regards,
Andrei.

-----Original Message-----

<javascript:;>]

Sent: Donnerstag, 11. September 2014 09:42
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

Post by Andrei Shakirin
full

deployed

attachments

Post by Andrei Shakirin
to

this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information.

Post by Andrei Shakirin
you are

not the intended recipient, please notify Lars-Fredrik Smedberg

immediately at

message and any