[JBoss JIRA] (JBTM-1058) Migrate WS-TF endpoint to Openshift
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1058?page=com.atlassian.jira.plugin.... ]
Paul Robinson resolved JBTM-1058.
---------------------------------
Resolution: Won't Fix
WS-TF is now closed.
> Migrate WS-TF endpoint to Openshift
> -----------------------------------
>
> Key: JBTM-1058
> URL: https://issues.jboss.org/browse/JBTM-1058
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 5.0.0.Final
> Reporter: Paul Robinson
>
> Currently our WS-TF endpoint (endpoint.jbossts.org) is hosted on Jonathan's personal infrastructure. We need to move it from here to somewhere else. Openshift seems like the obvious place to move it to.
> This is not seen as a high priority as the endpoint is currently down and no one has yet complained.
> Instructions from Andrew:
> {quote}
> endpoint.jbossts.org is publicised on the WSTF forum endpoints page. It is the host used for the test endpoints in WSTF scenarios 2, 3 + 7. All that is needed is to rehost the test services and then update the endpoint addresses. Paul and Alessio are both WSTF members and should be able to perform this update. The rehosting requires deploying the WSTF Scenario 2,3 and 7 wars to JBoss AS. These were running on Jonathan's host on AS6 last time I updated anything. They probably need dusting off in order to be sure they run ok on AS7.
> {quote}
--
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
12 years, 7 months
[JBoss JIRA] (JBTM-973) Allow lifecycle events to be handled by remote services
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-973?page=com.atlassian.jira.plugin.s... ]
Paul Robinson resolved JBTM-973.
--------------------------------
Assignee: Paul Robinson
Fix Version/s: 5.0.0.M5
Resolution: Won't Fix
I'm not sure this is something anyone would want to do. Will re-open when we get a clear use-case.
> Allow lifecycle events to be handled by remote services
> -------------------------------------------------------
>
> Key: JBTM-973
> URL: https://issues.jboss.org/browse/JBTM-973
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M5
>
>
> The lifecycleClass attribute on @ServiceRequest and @ParticipantService needs to support remote services, such as EJB or Web services. This allows the events to be handled in a remote container.
> We need to decide how and what context is passed to the remote service. Clearly the remote service needs some context to know what action to take. However, simply flowing the TX context may not be appropriate as the lifecycle methods will be invoked during termination of the protocol.
--
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
12 years, 7 months
[JBoss JIRA] (JBTM-976) Support multiple lifecycle methods of the same type targeted at the same ServiceRequest
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-976?page=com.atlassian.jira.plugin.s... ]
Paul Robinson resolved JBTM-976.
--------------------------------
Assignee: Paul Robinson
Fix Version/s: 5.0.0.M5
Resolution: Out of Date
No longer applicable for the Compensations API
> Support multiple lifecycle methods of the same type targeted at the same ServiceRequest
> ---------------------------------------------------------------------------------------
>
> Key: JBTM-976
> URL: https://issues.jboss.org/browse/JBTM-976
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M5
>
>
> A LifecycleClass implementation should be able to register multiple methods with the same Lifecycele annotation. For example, this would allow more than one compensation method to be triggered.
> Example:
> {code}
> @ServiceRequest()
> public void submitOrder(...)
> {
> ...
> }
> @Compensate
> public void cancelOrder()
> {
> //Cancel the order
> }
> @Compensate
> public void notifyAdmin()
> {
> //Notify an admin that an order was cancelled.
> }
> {code}
--
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
12 years, 7 months
[JBoss JIRA] (JBTM-977) Specify the order in which lifecycle methods are invoked when multiple of the same type exist
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-977?page=com.atlassian.jira.plugin.s... ]
Paul Robinson resolved JBTM-977.
--------------------------------
Assignee: Paul Robinson
Fix Version/s: 5.0.0.M5
Resolution: Out of Date
No longer applicable for the Compensations API
> Specify the order in which lifecycle methods are invoked when multiple of the same type exist
> ---------------------------------------------------------------------------------------------
>
> Key: JBTM-977
> URL: https://issues.jboss.org/browse/JBTM-977
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M5
>
>
> The 'order' attribute on Lifecycle callback annotations (e.g. @Compensate, @Prepare) can be used to ensure that certain lifecycle callbacks precede others during lifecycle processing. Normally, callbacks are made in the reverse order to that in which their corresponding service request was made. FIRST indicates that the callback should be executed before other NORMAL callbacks registered for the same lifecycle event. LAST indicates that the callback should be executed after other NORMAL callbacks registered for the same lifecycle event. Multiple FIRST or LAST callbacks are sorted in reverse order of registration.
> Example:
> {code}
> @ServiceRequest()
> public void submitOrder(...)
> {
> ...
> }
> @Compensate
> public void cancelOrder()
> {
> //Cancel the order
> }
> @Compensate(order=ExecutionOrder.LAST)
> public void notifyAdmin()
> {
> //Notify an admin that an order was cancelled.
> }
> {code}
--
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
12 years, 7 months
[JBoss JIRA] (JBTM-1096) Provide @CompensatedBy annotation
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1096?page=com.atlassian.jira.plugin.... ]
Paul Robinson resolved JBTM-1096.
---------------------------------
Assignee: Paul Robinson
Fix Version/s: 5.0.0.M5
Resolution: Out of Date
Something similar is now offered by the Compensations API
> Provide @CompensatedBy annotation
> ---------------------------------
>
> Key: JBTM-1096
> URL: https://issues.jboss.org/browse/JBTM-1096
> 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.M5
>
> Original Estimate: 2 days
> Time Spent: 1 day, 4 hours
> Remaining Estimate: 4 hours
>
> For example, take this business logic:
> {code}
> public class LifecycleImpl
> {
> @CompensatedBy(methodName="compensate1")
> public void doWork1()
> {
> //Do work1
> }
> @CompensatedBy(methodName="compensate2")
> public void doWork2()
> {
> //Do work2
> }
> public void compensate1()
> {
> //Compensate work1
> }
> public void compensate2()
> {
> //Compensate work2
> }
> }
> {code}
> Here different compensation methods are specified for the business logic methods 'doWork1' and 'doWork2'. For each call to doWork1, there needs to be a compensation participant registered in that BA, configured with the right compensate method. I think a developer would expect one call of the corresponding compensate, per call to doWorkX. I think the developer would also expect some way of knowing what work they where compensating. For example, having matching parameters and values for the work and compensate methods would allow the compensate to know what it was compensating.
> This is not going to be trivial to implement as it will probably require some re-factoring to work.
--
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
12 years, 7 months
[JBoss JIRA] (JBTM-1753) Merge TXFramework and CompensationsAPI-prototype
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1753?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1753:
--------------------------------
Priority: Minor (was: Major)
> Merge TXFramework and CompensationsAPI-prototype
> ------------------------------------------------
>
> Key: JBTM-1753
> URL: https://issues.jboss.org/browse/JBTM-1753
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M5
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> The current implementation of the compensations API was a quick prototype I knocked up ready for JUDCon. It needs merging into the existing TXFramework API.
> This will need some investigation as there are now multiple ways of doing the same thing. We need to decide which or both to keep.
--
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
12 years, 7 months
[JBoss JIRA] (JBTM-1838) Document how to configure XTS to use SSL
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1838?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1838:
--------------------------------
Fix Version/s: 5.0.0.Final
(was: 5.0.0.M5)
> Document how to configure XTS to use SSL
> ----------------------------------------
>
> Key: JBTM-1838
> URL: https://issues.jboss.org/browse/JBTM-1838
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator, Documentation
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 1 day
> Time Spent: 1 day
> Remaining Estimate: 4 hours
>
> The documentation should show how to use 'https' for all communications.
> I'm not sure what form the documentation should take. Given that the majority of configuration is actually related to enabling SSL for Web Services in general, I don't think it should all live in the XTS docs. Maybe we just add the XTS specific stuff there and link to the docs on how to enable SSL for WS.
> We could also provide a JDF quickstart. However, the docs comprise of many bash commands, so this may not fit in well with a quickstart.
> Other options are a community wiki page or blog posting.
--
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
12 years, 7 months