[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1398:
-------------------------------------
Especially if the only reason is to prevent us from having to have 2 subsytems ;-)
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 days
> Time Spent: 1 day, 7 hours
> Remaining Estimate: 2 days, 6 hours
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1398:
-------------------------------------
Tom,
I don't see a compelling reason to spit Weld into two subsytems, so I don't think that's going to work.
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 days
> Time Spent: 1 day, 7 hours
> Remaining Estimate: 2 days, 6 hours
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Paul Robinson logged work on JBTM-1398:
---------------------------------------
Author: Paul Robinson
Created on: 16/Jan/13 9:49 AM
Start Date: 16/Jan/13 9:49 AM
Worklog Time Spent: 2 hours
Issue Time Tracking
-------------------
Remaining Estimate: 2 days, 6 hours (was: 3 days)
Time Spent: 1 day, 7 hours (was: 1 day, 5 hours)
Worklog Id: (was: 12428408)
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 days
> Time Spent: 1 day, 7 hours
> Remaining Estimate: 2 days, 6 hours
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1432) Provide information about the uid of the transaction that you are aborting
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-1432:
-----------------------------------
Summary: Provide information about the uid of the transaction that you are aborting
Key: JBTM-1432
URL: https://issues.jboss.org/browse/JBTM-1432
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transaction Core
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Fix For: 4.17.4, 5.0.0.M2
I came across the following investigating a support case:
https://community.jboss.org/wiki/TxMultipleThreads
This article is excellent, however it highlighted to me a slight deficiency in the "The transaction is not active!" log statement.
I think we should put the uid of the transaction in this statement too, this can then be cross referenced against the statement: "Abort of action id -3f57cb74:c9a4:499eb149:a92 invoked while multiple threads active within it."
It would look something like: "The transaction is not active! Uid is -3f57cb74:c9a4:499eb149:a92"
This means that without turning on tracing you can be sure that your XAR was not wedged because you can see the business logic at least attempting to complete the transaction. It will also be useful to help a customer determine a suitable timeout value as often the logging is accompanied by timestamps so it will be quite straight forward to work out how much longer to add to the timeouts.
As I mentioned, this information *is* available today, but you have to enable tracing on the logging which is not always acceptable in a production environment.
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1398:
-------------------------------------
Should org.jboss.as.weld.deployment.WeldAttachments be lifted into its own subsystem that doesn't depend on EJB3?
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 days
> Time Spent: 1 day, 5 hours
> Remaining Estimate: 3 days
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1398:
-------------------------------------
We need the org.jboss.as.jboss-as-weld dependency to use this: org.jboss.as.weld.deployment.WeldAttachments. This is needed to register the CDI Extension. I don't know of a way of avoiding this dependency.
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 days
> Time Spent: 1 day, 5 hours
> Remaining Estimate: 3 days
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1430) Restore commit method to AtomicAction
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1430?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1430:
-----------------------------------
It's possible that some of the deprecations have been fixed. I was looking at the 4.16 branch at the time.
> Restore commit method to AtomicAction
> -------------------------------------
>
> Key: JBTM-1430
> URL: https://issues.jboss.org/browse/JBTM-1430
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.3
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> At some point someone deprecated the commit method in AtomicAction and left the following comment:
> @deprecated Only used by tests
> This is wrong. Just because we don't use the commit method in the code does not mean it is invalid in the scope of the public API. The commit method without the boolean parameter is a helper method to simplify calling the other commit with true all of the time. This was added years ago based on feedback from the OTS Current implementation, which had (in C++) a default boolean=true parameter in its signature.
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1430) Restore commit method to AtomicAction
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1430?page=com.atlassian.jira.plugin.... ]
Mark Little updated JBTM-1430:
------------------------------
Affects Version/s: 4.16.6
(was: 4.17.3)
> Restore commit method to AtomicAction
> -------------------------------------
>
> Key: JBTM-1430
> URL: https://issues.jboss.org/browse/JBTM-1430
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.6
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> At some point someone deprecated the commit method in AtomicAction and left the following comment:
> @deprecated Only used by tests
> This is wrong. Just because we don't use the commit method in the code does not mean it is invalid in the scope of the public API. The commit method without the boolean parameter is a helper method to simplify calling the other commit with true all of the time. This was added years ago based on feedback from the OTS Current implementation, which had (in C++) a default boolean=true parameter in its signature.
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1430) Restore commit method to AtomicAction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1430?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1430:
-------------------------------------
Sure, after committing https://github.com/jbosstm/narayana/commit/43e7bdd94cce6ec051587dcdc43313..., I have repeated my search for @deprecated and can't find anything else problematic.
FYI, this is the search I am using to find public deprecated methods, until you update you will also see the ones I have fixed:
[tom@localhost narayana](master) $ find . -name \*.java -exec grep -l "@deprecated" {} \; | grep -v internal
./txbridge/src/main/java/org/jboss/jbossts/txbridge/inbound/InboundBridgeManager.java
./ArjunaJTS/jts/classes/com/arjuna/ats/jts/recovery/RecoveryEnvironment.java
./ArjunaJTS/integration/src/main/java/com/arjuna/ats/jbossatx/jta/TransactionManagerService.java
I have looked at these remaining deprecations and they appear to be OK, certainly they are not ones that refer to tests.
> Restore commit method to AtomicAction
> -------------------------------------
>
> Key: JBTM-1430
> URL: https://issues.jboss.org/browse/JBTM-1430
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.3
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> At some point someone deprecated the commit method in AtomicAction and left the following comment:
> @deprecated Only used by tests
> This is wrong. Just because we don't use the commit method in the code does not mean it is invalid in the scope of the public API. The commit method without the boolean parameter is a helper method to simplify calling the other commit with true all of the time. This was added years ago based on feedback from the OTS Current implementation, which had (in C++) a default boolean=true parameter in its signature.
--
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
13 years, 2 months
[JBoss JIRA] (JBTM-1430) Restore commit method to AtomicAction
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1430?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1430:
-----------------------------------
If methods were added purely for the tests, then I can understand (though there are better ways of doing this than deprecating). But it's methods like AtomicAction.commit and StatementManager.deactivate (to name but 2) that weren't added for tests and yet have been deprecated that worries me. I haven't done an exhaustive trawl of the code to find others.
> Restore commit method to AtomicAction
> -------------------------------------
>
> Key: JBTM-1430
> URL: https://issues.jboss.org/browse/JBTM-1430
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.3
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> At some point someone deprecated the commit method in AtomicAction and left the following comment:
> @deprecated Only used by tests
> This is wrong. Just because we don't use the commit method in the code does not mean it is invalid in the scope of the public API. The commit method without the boolean parameter is a helper method to simplify calling the other commit with true all of the time. This was added years ago based on feedback from the OTS Current implementation, which had (in C++) a default boolean=true parameter in its signature.
--
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
13 years, 2 months