[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:
--------------------------------

    Description: 
h2. Create:

* JTAOverWSATFeature
* Configuration option on the XTS Subsytem (defaultContextPropagation)

h2. Semantics:

h4. JTAOverWSATFeature absent, defaultContextPropagation disabled
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. JTAOverWSATFeature absent, defaultContextPropagation enabled (Default OOTB)
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. JTAOverWSATFeature enabled, defaultContextPropagation disabled
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. JTAOverWSATFeature disabled, defaultContextPropagation enabled
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:

# <defaultContextPropagation enabled=”true” /> (default OOTB config)
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.

# <defaultContextPropagation enabled=”false” />
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.

# Config absent.
Error. Fail config parse.


h5. Bridge handler
Two handlers that delegate to the existing TXBridge handler:

# Disabled by default. Only invokes the TXBridge handler if the JTAOverWSATFeature is present and enabled.
# Enabled by default. Always invokes the TXBridge handler unless the JTAOverWSATFeature is present and disabled.

If the bridge detects the JTAOverWSATFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAOverWSATFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.




  was:
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. 





    
> 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:
> * JTAOverWSATFeature
> * Configuration option on the XTS Subsytem (defaultContextPropagation)
> h2. Semantics:
> h4. JTAOverWSATFeature absent, defaultContextPropagation disabled
> 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. JTAOverWSATFeature absent, defaultContextPropagation enabled (Default OOTB)
> 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. JTAOverWSATFeature enabled, defaultContextPropagation disabled
> 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. JTAOverWSATFeature disabled, defaultContextPropagation enabled
> 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:
> # <defaultContextPropagation enabled=”true” /> (default OOTB config)
> 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.
> # <defaultContextPropagation enabled=”false” />
> 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.
> # Config absent.
> Error. Fail config parse.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAOverWSATFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAOverWSATFeature is present and disabled.
> If the bridge detects the JTAOverWSATFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAOverWSATFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.

--
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