geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: need help on Tomcat and EJB web services
Date Tue, 17 Apr 2007 15:55:33 GMT
Why not use a low level Valve to trap the HTTP call before a redirect
can occur?


David Jencks wrote:
> On Apr 17, 2007, at 8:02 AM, Paul McMahan wrote:
>> 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:
>> 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:
>> 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.
> My guess is this is the best bet, but I couldn't figure out what context
> root and servlet-mapping would apply to  an ejb web service.  Does
> tomcat let you deploy a lot of apps at the same context-root?  If so,
> perhaps we can deploy each ejb-ws at "/"
> I'm not very worried about the tomcat implementation being different
> from the jetty implementation.  I'm more worried about this being a lot
> of work.  We might need to implement the tomcat object that runs
> Digester to construct the servlet wrapper for us.
> thanks
> david jencks
>> 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

View raw message