Announcement Announcement Module
Collapse
No announcement yet.
Suggested improvements to XPathParamAnnotationMethodEndpointAdapter Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Suggested improvements to XPathParamAnnotationMethodEndpointAdapter

    I really do like the concept of XPathParam annotations, they are especially nice for mye current project, as we have some web service request definitions that tend to include much more information than my web service endpoints really need.

    The lack of support for Integers and primitives is somewhat annoying, cluttering up the code, but the biggest problem is with more complex data types.

    All of our web service methods have a UserContext object as one of their parameters. Using @XPathParam annotations for each of its fields is obviously not a very pretty solution, getting the root node of the UserContext object as a Node could work, but then we'd have to call a util method for converting that into a UserContext object in each and every endpoint.

    I've submitted two issues with patches offering a solution for this, they are SWS-557 and SWS-558 in Jira.

    These two patches makes it possible to create ParamConverter classes, each one being able to convert one or more xml data types into java objects. Using the new ExtendableXPathParamAnnotationMethodEndpointAdapte r as the endpoint adapter lets you register these converters using the application context, and you can then define your endpoints like this:

    Code:
        public void sameplEndpointMethod(@XPathParam("/root/child/text") String par,
                @XPathParam("/root/child/userContext") UserContext userContext) {
        }
    I find my patches useful, as they move the messy conversion code away from my endpoint code, which is what I really like the XPathParam annotations to do.

    Any questions or feedback would be greatly appreciated.



    Eivind
Working...
X