UT00009 error on deploying a SOAP Web Service: "does not implement javax.servlet.Servlet". Cause?

[tuijldert]

Hi all,

On deploying a WebService as a global module, I consistently get this error in Wildfly 10:

java.lang.IllegalArgumentException: UT010009: Servlet ...of type class ... does not implement javax.servlet.Servlet

Google-ing just hints at a server.jar which might be accidentally included but I can't find it...

Any other ideas on what could cause this error?

Thanks in advance,

Tom.

[jewellgm]

Does your module include a "servlet" (not "server") jar?  Wildfly bundles its own implementation of the Servlet class in the servlet\api module.  It's entirely possible that you are having a classloading issue where two definitions of the Servlet class are in use.  If you have that jar, then you'll need to remove it, and then make your module depend on the servlet module already within wildfly.

[tuijldert]

Aha, the plot thickens. Thanks for this hint on where to look, I did some more experimenting on this.

When building the Web Service entirely in a WAR, it starts flawlessly and one can access the wsdl.

Subsequently taking out the class that defines the actual service (using @WebService etc), packaging it in a jar and converting it to a global module produces the error.

If I don't specify a dependency in module.xml, the naming definitions cannot be found.

If I add the dependency on javax.api, that error is gone but now I get the above mentioned servlet error.

So if I have all in deployments, the user classloader has no trouble finding the necessary (and correct!) dependencies, which is consistent with what the Webservice reference guide tells me (I think).

However, on morphing part of the code into a Wildfly module, dependencies have to be explicitly specified, but merely javax.api doesn't do the trick.

The chapter on jboss modules and WS applications within that reference guide doesn't help either.

So the question becomes, what dependencies need to be specified in module.xml to untangle this class-'spaghetti'?

Any hints, much appreciated.

TIA,

Tom.

[jewellgm]

It sounds like, at the very least, you'll need:

javax.api

javax.servlet.api

I don't know what else is in your code.  I'd suggest adding those two modules as dependencies and trying again. If you get another error, then additional modules may be needed.

Edit:

It's been a while since I worked on a project that utilized SOAP web services, so I don't remember the modules that we had as dependencies.  You may want to try depending on "org.jboss.ws.api" module.  It already depends on the javax.naming module and a few others.  I haven't traced it through, but I'm guessing that one of the other dependencies also depends on javax.servlet.api.

Edit 2:

Does your WAR file list any dependencies in the MANIFEST.MF file?  You may be able to just copy those....

[tuijldert]

Hi,

Thanks for the suggestion.

And indeed, that was my thinking as well.

So I've tried just about any and every permutation and ordering of javax.api, javax.servlet.api, org.jboss.ws.api, system naming and a whole bunch of others that I could find but basically it comes down to:

- If a dependency on javax.api (or a partial javax.naming) is specified, it immediately complains about my class not implementing the Servlet.

- In all other cases, classes in javax.naming are consistently not found.

So, where the marketing blurb promises an "escape from jar-hell", it definitely -in module space at least- doesn't provide an "escape from dependency hell"

Given the time I already spent on this, I'll probably leave it at this and contend myself with multiple library copies or something.

Thanks immensely for the help and enjoy the weekend.

Cheers,

Tom.

[jewellgm]

I'm wondering whether WildFly just doesn't support this configuration.  It sounds the web service should be turned into a JCA adapter since it could (potentially) accept connections from external clients.

[mpmiller37]

Having similar issue using @WebService annotation in wsdl based service classes.  These classes are indicated as servlets in the web.xml using the <servlet> tag(s).  Have a look at the RedHat article:

https://access.redhat.com/solutions/2722571

The article implies that if WildFly thinks any class is a servlet then it expects it to implement the Servlet interface otherwise the service will fail to start with error indicated.  I was able to deploy by implementing the interface and leaving the servlet methods empty.  Though I'm not sure yet if/how this will affect my webservices.