[jbossts-issues] [JBoss JIRA] (JBTM-1447) Create WebserviceFeature for TXBridge

[Paul Robinson (JIRA)]

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

Paul Robinson updated JBTM-1447:
--------------------------------

    Priority: Major  (was: Minor)

    
> Create WebserviceFeature for TXBridge
> -------------------------------------
>
>                 Key: JBTM-1447
>                 URL: https://issues.jboss.org/browse/JBTM-1447
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: TxBridge
>            Reporter: Paul Robinson
>            Assignee: Paul Robinson
>             Fix For: 5.0.0.M2
>
>   Original Estimate: 1 day
>          Time Spent: 2 hours
>  Remaining Estimate: 1 day, 4 hours
>
> h2. Create:
> * JTAtoWSTXFeature
> * Configuration option on the XTS Subsytem. Lets call it "ByDefaultBridgeFromJTA" for now, subject to change.
> h2. Semantics:
> h4. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA absent (Default OOTB)
> This is the current OOTB experience for EAP 5&6. No handlers are activated automatically. The developer has to add them manually for all ports.
> h4. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA present
> All Web service requests that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header.
> h4. JTAtoWSTXFeature enabled, ByDefaultBridgeFromJTA absent
> All Web service requests, for this port, that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header.
> h5. JTAtoWSTXFeature disabled, ByDefaultBridgeFromJTA present
> All Web service requests, for this port, don't bridge JTA.
> h2. Implementation
> The XTS Subsystem reads its config on boot. It carries out one of the following actions depending on what it finds:
> # <propagateByDefault/> or <propagateByDefault bridgeJTAByDefault='false'/>
> Just do [JBTM-986].
> # <propagateByDefault bridgeJTAByDefault='true'/>
> Add the Bridge handler initialized to be enabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> # No propagateByDefault Element
> Config absent. Add the Bridge handler initialized to be disabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> 'bridgeJTAByDefault' is an attribute of 'propagateByDefault' as 'bridgeJTAByDefault' depends on 'propagateByDefault' being present.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAtoWSTXFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAtoWSTXFeature is present and disabled.
> If the bridge detects the JTAtoWSTXFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAtoWSTXFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> h5. Existing handler changes
> We may need to change the TXBridge handler to tolerate the scenario where no JTA transaction is present. Fail silently if JTAtoWSTXFeature missing, but throw an Exception if JTAtoWSTXFeature is set. It is assumed that if the port has JTAtoWSTXFeature enabled, there should be a JTA transaction in place. This matches the the current semantics: if the developer adds the TXBridge handler, throw an Exception if no JTA present. This also allows the developer to add a sanity check (set the JTAtoWSTXFeature) to make sure that the call is only ever called in the context of a JTA transaction. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira