views:

351

answers:

1

I've got a service running at a fixed location in the network, with a WSDL attached etc. I can easily create a jax-ws client with wsimport and the usual stuff when doing this stand-alone, but I'd really like to be able to call this service from inside another web application.

Unfortunately I'm running into some gotchas here. For one, everything works pretty well in a regular web container, but not on jboss, which apparently puts some incompatible classes in the endorsed directory making deployment fail with:

java.lang.ClassCastException: com.sun.xml.ws.client.WSServiceDelegate cannot be cast to javax.xml.ws.spi.ServiceDelegate21

There's a blog entry somewhere that proposes to fix this by deleting the endorsed jax-ws jars, but this might end up breaking something else on this particular server and so I was wondering if there isn't a better way to isolate this further? Completely relying on j2ee specific support is possibly an option but I'd really like to retain the ability to deploy the app on a simple web container as well (jetty, tomcat, ...).

+3  A: 

My advice is to forget JAX-WS on the client. It's complicated and not as portable as it thinks it is, and is often an integration headache.

I suggest a more lightweight web service client, such as Spring-WS's WebServiceTemplate. It will support your existing wsimport-generated JAXB bindings, but will ignore the JAX-WS stuff. It's simple, easy and will run in anything from a full JBoss stack to a Jetty application without butting heads with existing frameworks.

skaffman
+1 for headache
Andreas_D
I think it's telling nobody else bothered to chime in. I'll just switch to using spring-ws then, thanks.
wds