Jarek and I have been struggling with an issue we encountered in
Geronimo's TomcatEJBWebService that has to do with how EJB web
services become URL addressable after they are deployed. You can
see the full discussion here:
https://issues.apache.org/jira/browse/GERONIMO-2841
In a nutshell, the basic problem is that when an HTTP client requests
http://hostname/context Tomcat will automatically redirect the
request to http://hostname/context/ (note the trailing slash). This
behavior is mandated by section 9.10 of the servlet 2.4 specification
which says:
"A request URI of /foo will be redirected to a URI of /foo/"
The reason this behavior causes a problem for our web services
implementation is because when Geronimo's EJBWebServiceGBean deploys
a web service it uses a context without the trailing slash, e.g. "/
JAXWSBeanService/JAXWSBean". Then a web service client sends a POST
request to that location, http://hostname/JAXWSBeanService/JAXWSBean,
Since that URL corresponds to a context Tomcat responds with a
redirect URL that appends the trailing slash. Jarek has found that
this redirect causes a problem for web service clients because they
will respond to it with a GET instead of a POST, thus losing the
original method and structure of the request by the time it reaches
the web services container.
In case you're wondering, Jetty also exhibits this redirect behavior
by default and Geronimo's JettyEJBWebService avoids it by overriding
ContextHandler.handle(). But Tomcat implements this redirect
behavior at the connector level and and I have not found any
reasonable way to override it (maybe I am overlooking something). It
used to be configurable but that support was explicitly removed:
http://svn.apache.org/viewvc?view=rev&revision=298787
At this point we have identified the following options. Any feedback
you can provide would be very helpful.
1.) Figure out some clever way to "outsmart" Tomcat and avoid the
redirect behavior. I haven't found any way to do this but maybe
someone else has an idea. Maybe this is not desirable since it
arguably violates the servlet spec.
2.) Ask Tomcat to reimplement the configuration option they removed
in rev 298787 that would allow us to avoid the redirect behavior.
Again, maybe not desirable since it arguably violates the servlet spec.
3.) Redesign TomcatEJBWebService to deploy web services as servlets
instead of contexts. This would be a significant design change and
would also be inconsistent with our current implementation in Jetty.
4.) Expect web service clients to follow redirects more
intelligently, i.e. respond to a redirect from a POST request with
another POST instead of a GET. IIUC this may cause problems with
TCK? (Jarek can elaborate).
5.) other ideas?
Best wishes,
Paul
