[jbossts-issues] [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain

Paul Robinson (Updated) (JIRA) jira-events at lists.jboss.org
Wed Nov 30 08:22:40 EST 2011


     [ https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Robinson updated JBTM-986:
-------------------------------

    Priority: Minor  (was: Major)

    
> Automatically setup the client side handler chain
> -------------------------------------------------
>
>                 Key: JBTM-986
>                 URL: https://issues.jboss.org/browse/JBTM-986
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Paul Robinson
>            Priority: Minor
>             Fix For: 5.0.0.M2
>
>
> When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the client stub to manage transaction context propagation. The code required to do this is as follows:
> {code}
> BindingProvider bindingProvider = (BindingProvider) client;
> List<Handler> handlers = new ArrayList<Handler>(1);
> handlers.add(new JaxWSHeaderContextProcessor());
> bindingProvider.getBinding().setHandlerChain(handlers);
> {code}
> This is not very user friendly.
> h2. Using WS-Policy
> If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is required/supported and we should be able to setup this handler chain automatically. Another benefit is that we can catch, on the client side, the situation where no WS-AT or WS-BA transaction context is present. Currently we leave it up to the service to detect and as a result we have no control over how this fault will be propagated back to the client. For example, a WrongStateException could be thrown when the service tries to enlist a participant and a transaction is not present. The Client may receive a generic fault message back or, in this case some or all of the WrongStateException. In either case, the developer of the Client is unlikely to realise that this is due to there not being a transaction present when the service was invoked. If the service mandates a WS-AT or WS-BA transaction, but none is present, then the client handler throws a suitable exception explaining what went wrong. If the service supports (i.e. it is optional) a WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
> CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be the right integration point for this feature. This is to be investigated.
> h2. Without WS-Policy
> It could be possible to inject a WS client stub and annotate the injection point such that the middleware knows to setup the handler chain. I'm not sure what support already exists for injecting WS client stubs. This needs to be investigated first.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



More information about the jbossts-issues mailing list