sws:annotation-driven + custom edpoint mapping + endpoint adapter = problem

[trojanbug]

Hi,

I tried to implement some scenario, when the endpoint mapping is URI suffix dependent.
I have a pretty untypical endpoint, that accepts some JDom Element, and return a Source - and this works perfectly when used together with @PayloadRoot(localPart = "myRequest", namespace = "http://www.example.org/sample") annotation + sws:annotation-driven, probably with help of JDomPayloadMethodProcessor + DefaultMethodEndpointAdapter registered by sws:annotation-driven instruction.

I expected no difference after adding my custom endpoint mapping, cause I though the adapters will be registered as they were. I have just ensured that my mapping is executed first, by using -100 in the order.

...
    <sws:annotation-driven />
  
       <bean class="my.test.URISuffixEndpointMapping">
        <property name="suffixMappings">
            <list>
                <bean class="my.test.URISuffixEndpointMapping$URISuffixToEndpointMappingEntry">
                    <property name="suffix" value="/VerySpecialSuffix"/>
                    <property name="endpoint" ref="jdom-test-endpoint"/>
                </bean>
            </list>
        </property>
        <property name="order" value="-100"/>
    </bean>
    
    <bean id="test-endpoint" class="example.TestEndpoint"/>
    <bean id="jdom-test-endpoint" class="example.JDomTestEndpoint"/>
...

The endpoint is something like:

@Endpoint
public class JDomTestEndpoint {

// commeted  as not using PayloadRoootQName 
//@PayloadRoot(localPart = "myRequest", namespace = "http://www.example.org/my")

    @ResponsePayload
    public Source getPropertyMyResponse(@RequestPayload Element myRequest) {
        Namespace ns = Namespace.getNamespace("http://www.example.org/my");
        
        return new StringSource(
                "<myResponse xmlns='http://www.example.org/my'>"
                + "<objectValue>"
                + "Received " + myRequest.getChildText("testQuery", ns)    
                + "</objectValue>"
                + "</myResponse>");
    }
}

To my surprise this however does not work, saying that it cannot fidn an EndpointAdapter for my endpoint. I can see it tries to reach the endpoint (as it mentions its class as not being able to be adapted), I can see default mappings are registered, as the other endpoint works and responds.

Is there any possibility that registering my endpoint mapping would prevent from registering or wiring the DefaultMethodEndpointAdapter, or the JDomPayloadMethodProcessor ?
How come there is a symmetry break ?

I am on Spring-WS 2.0.2 + Spring 3.0.5 on Tomcat 7.0.11.

Need some suggestions desperately

Cheers,
Chris

[trojanbug]

Some additions:

I have just confirmed in debug, that AnnotationDrivenBeanDefinitionParser.registerEndpo intAdapters() is called as usual.
So, the DefaultMethodEndpointAdapter should be registered.

But, I tried to see if it is ever tried, by putting a breakpoint in DefaultMethodEndpointAdapter "supportsInternal" - and the execution never got it. So there is something that makes the settings done by sws:annotation-driven ineffective.

Should there be some EndpointAdapter registration done with the EndpointMapping ? I don't think so ... but pls help.

[trojanbug]

Hi All,

I think I have figured it out. I think there is a design bug in the entire construct, but it may be hard to eliminate at this level.

The problem is that basically EndpointMappings, that I would normally expect to do just what the name implies - map from the MessageContext to the endpoint, have addtional hidden responsibilities. One of such responsibilities is wrapping the endpoint with MethodEndpoint, if the endpoint is implemented at the individual method level.

In the MessageDispatcher there is a check: "endpoint instanceof MethodEndpoint", and only if it is true then the EndpointAdapter are queried with "supports" method with the Endpoint argument.

I think this is a poor design. Normally I would say it is the adapter's responsibility to decide if the adapter can handle a given adaptee (Endpoint in this case). What stops us from having AnnotatedMethodAdapter ... I think the construct was trying to solve the problem of communicating the EndpointMapping configuration to the adapter level (otherwise how the adapter would know which method to call ?), but I don't like the solution.

I can leave with that, adding additional implementation extending AbstractMethodEndpointMapping instead of AbstractEndpointMapping.

But once again - I simply would not expect the endpoint _MAPPING_ to be anything more than mapping, but instead trying to bridge any impendance mismatch.

Cheers,
Chris