]
Paul Robinson logged work on JBTM-1447:
---------------------------------------
Author: Paul Robinson
Edited by: Paul Robinson
Created on: 11/Feb/13 9:20 AM
Edited on: 11/Feb/13 9:21 AM
Start Date: 11/Feb/13 9:19 AM
Worklog Time Spent: 2 hours (was: 1 day)
Work Description: We also need to test every scenario. Hopefully we can use the
same pattern as [JBTM-986].
Issue Time Tracking
-------------------
Remaining Estimate: 1 day, 4 hours (was: 2 days)
Time Spent: 2 hours (was: 1 day)
Worklog Id: (was: 12428696)
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: