CODEWITHSUNDEEP
javaweb-servicessoapglassfishspring-ws
Nick
Nick

Reputation: 449

Spring-WS based SOAP service returns a 405 when deployed in Glassfish

This one seems a little odd to me - I have a very basic SOAP service built in Spring-WS that deploys & runs just fine inside a Tomcat 7 container. I have been experimenting with Glassfish 4 lately & trying to get this SOAP service working but get a "405 Method Not Allowed" every time I try to test a call via SoapUI.

Does anyone have any advice on what might cause this? It's the exact same WAR deployed into both containers - the only change I made was a tweak to my datasource JNDI lookup in my service layer, everything else is identical.

The really strange thing is that, when deployed in Glassfish, it'll serve up the WSDL (i.e. localhost:8080/user-soap-service/user.wsdl), so I know the application is deployed/listening on that URL - it just refuses to let any POSTs through it seems.

This is my web.xml:

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
    <servlet>
        <servlet-name>user-soap-service</servlet-name>
        <servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>user-soap-service</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

And this is my application context:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:context="http://www.springframework.org/schema/context"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
                       http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                       http://www.springframework.org/schema/context
                       http://www.springframework.org/schema/context/spring-context-2.5.xsd">

    <context:annotation-config/>
    <import resource="classpath:user-service.xml"/>

    <bean id="userService" class="com.myorg.service.user.services.UserServiceBean"/>

    <bean class="org.springframework.ws.server.endpoint.mapping.PayloadRootAnnotationMethodEndpointMapping"/>

    <bean id="userEndpoint" class="com.myorg.api.endpoints.UserMarshallingEndpoint"/>

    <bean class="org.springframework.ws.server.endpoint.adapter.GenericMarshallingMethodEndpointAdapter">
        <property name="marshaller" ref="marshaller"/>
        <property name="unmarshaller" ref="marshaller"/>
    </bean>

    <bean id="marshaller" class="org.springframework.oxm.castor.CastorMarshaller">
        <property name="mappingLocation" value="classpath:mapping.xml"/>
    </bean>

    <bean id="user" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition">
        <property name="schema">
            <bean class="org.springframework.xml.xsd.SimpleXsdSchema">
                <property name="xsd" value="/WEB-INF/user.xsd"/>
            </bean>
        </property>
        <property name="portTypeName" value="User"/>
        <property name="locationUri" value="http://localhost:8080/user-soap-service"/>
    </bean>
</beans>

Everything deploys fine (no errors/warnings) and if I compare the WSDL served up when it's deployed in Tomcat vs what it looks like when it's deployed in Glassfish, they are identical. Does anyone have any thoughts on what could be happening?

UPDATE This is really unexpected, but it works fine with good old fashioned curl (I had previously been testing with SoapUI). I'm now going to focus my research on how SoapUI is constructing its call vs what I'm doing with curl.

Upvotes: 1

Views: 4695

Answers (2)

pma
pma

Reputation: 921

This may also happen if you send your request using http while only https is allowed

Upvotes: 1

Nick
Nick

Reputation: 449

After some experimentation, the key thing here appears to be the "locationUri" property of my Spring wsdl definition.

When deployed into Tomcat (7.0.54 is the version I'm currently using), the application doesn't seem to care one bit if you are sending requests (either via SoapUI or curl) to localhost:8080/user-soap-service or localhost:8080/user-soap-service/ - the "locationUri" property doesn't seem to matter one bit in this sense (i.e. I get the exact same behavior whether I've put a trailing / or not).

When deployed into Glassfish (I'm currently on version 4), I get drastically different behaviors. No matter if I've used a trailing / in my config or not, making a request via curl using localhost:8080/user-soap-service will give me a 303. Making a request via SoapUI against that same URL will give me a 405! Adding a slash - i.e localhost:8080/user-soap-service/ - gives me a successful call using either curl or SoapUI.

Basically, up to this point, my testing would seem to indicate that the "locationUri" property doesn't do squat - I get the same behaviors no matter if I've used a trailing / at the end of that property's URL or not. However, it makes a big difference in how SoapUI constructs your default requests, as it constructs the URL to send requests against based on the WSDL you provide it - i.e.:

<wsdl:service name="UserService">
    <wsdl:port binding="tns:UserSoap11" name="UserSoap11">
        <soap:address location="http://localhost:8080/user-soap-service/"/>
    </wsdl:port>
</wsdl:service>

The moral of the story that I'm taking away from this is to always use a trailing slash on your Spring WSDL definition bean's "locationUri" property because - depending on your container & testing tool of choice, this can make a big difference in whether your tests go through or not.

Also, do not discount the power of good old curl to uncover something obvious you're overlooking!

Upvotes: 2

Related Questions