[Mike S.]

MyEclipse Team:

Can you give some insight into why you chose to leverage the Sun JAX-WS RI for your Web Services support, and why not something like Axis 2 or CXF?

Was there something compelling about Sun Metro or the included Sun JAX-WS RI that made the alternatives not really comparable?

Our issue with JAX-WS is that it doesn’t appear that you can use JAX-WS 2.0 in WebSphere 6.1.x without the Web Services feature pack, and that you won’t be able to use JAX-WS 2.1 until WebSphere 7.0 is released. What version of JAX-WS does MyEclipse 6.5 use?

Thanks,
Mike

[Riyad Kalla]

Mike,
We’ve always tried to focus our tooling on standard compliancy (because our customers first and foremost demand it) and you are right that using WebSphere 6.1 you do need the feature pack installed to get access to the JAX-WS 2.0 support (note: MyEclipse Blue provides native JAX-RPC and JAX-WS support using the WebSphere runtime if you are interested).

We currently support the JavaEE-5 spec compliant JAX-WS 2.0 standard in MyEclipse 6.5.

[mcs13099]

Well..I sort of cringed when I saw this post and just had to reply…because we had similar issues. – We also use Websphere 6.1 and wanted to use JAX-WS. However, we were determined to not be forced to use IBM-flavored ways when implementing what should be open source technologies.

We had already been down that road too many times at the expense of portability. The criteria – if I developed a JAX-WS web service, I should be able to take the same WAR file and drop it on Tomcat, Glassfish, OR Websphere and it should just work w/o hacking around – AND we did just that. In fact we specifically DID NOT INSTALL the “Web Services Feature” Pack – it caused nothing but issues and we just did not want to use Axis2. Sun Metro was our choice and we stuck with it and it does work.

Some key points:

1) create your JAX-WS WAR with all the necessary classes (both generated and your implementation classes)
2) include the sun-jaxws.xml file and web.xml files in the WEB-INF/ folder – you have to be sure to line up the url-pattern attributes between the 2 files so your endpoint will be reached.
3) include the JAX-WS RI jar files in the /WEB-INF/lib of your WAR – this is KEY #1.
4) KEY #2 – set the classloader policy for the WAR file in Websphere 6.1 (you can do this w/ the Admin Console) – this can be automated w/ the deployment as well – I just don’t recall the step for that at the moment. It should be set such that the Application classes load FIRST (ie: PARENT LAST).

Doing this and deploying onto Websphere 6.1 that has not been contaminated w/ the “WS Feature Pack” yields this:

[2/5/09 8:34:27:126 EST] 00000029 WebGroup A SRVE0169I: Loading Web Module: SyncActivityStatusWizard.war.
[2/5/09 8:34:27:204 EST] 00000029 http I WSSERVLET12: JAX-WS context listener initializing
[2/5/09 8:34:28:874 EST] 00000029 http I WSSERVLET14: JAX-WS servlet initializing
[2/5/09 8:34:28:876 EST] 00000029 ServletWrappe I SRVE0242I: [sac_sysApp] [/SyncActivityStatusWizard]
[SyncActivityStatusService]: Initialization successful.

The service handles the requests and performs just fine. Then…to prove it to ourselves, we dropped the exact same WAR file into a Tomcat6 installation’s /webapps folder – same results. However, in that case, no classloader policy was involved – it just worked.

Hope this helps.

[mcs13099]

forgot to mention in the last post – we were using Websphere 6.1.0.15 and JAX-WS RI 2.1.4. – https://jax-ws.dev.java.net/2.1.4/

[Author]

Posts