[JBoss JIRA] (JBTM-1769) Update readme.md to illustrate how to build individual profiles
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1769?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1769:
--------------------------------
Fix Version/s: 5.0.0.M5
> Update readme.md to illustrate how to build individual profiles
> ---------------------------------------------------------------
>
> Key: JBTM-1769
> URL: https://issues.jboss.org/browse/JBTM-1769
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System, Documentation
> Affects Versions: 5.0.0.M4
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.M5
>
>
> The following no longer works:
> ./build.sh clean -P core
> giving:
> WARNING] The requested profile "core" could not be activated because it does not exist.
> This is fine because I recall a discussion on the forums recently where this change was discussed. However, I thought that there would still be an equivalent way of doing this, but looking at the latest readme does not indicate how.
> What I'm looking for are the equivalents of the old build profiles.
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1330) Extend the transaction boundary of the transaction manager embedded in a JDBC compliant database to other resources which can support two-phase commit semantics such as XAResources
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1330?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1330.
---------------------------------
Resolution: Won't Fix
> Extend the transaction boundary of the transaction manager embedded in a JDBC compliant database to other resources which can support two-phase commit semantics such as XAResources
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1330
> URL: https://issues.jboss.org/browse/JBTM-1330
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Tom Jenkinson
>
> Where you multiplex the users application table and the transaction log in the same JDBC local transaction.
> LLR
> ===
> Resource 2 provides Coordinator
> Resource1 (xar1::prepare();) // sync 1
> Resource2 (ds1::insert(tmLog)
> ds1::commit() // sync 2)
> Resource 1 (xar1::commit(); // sync 3)
> Resource 1 (ds1::delete(tmLog))
> ds1::commit() // sync 4 (potentally lazy)
> XA
> ==
> Resource 1 (xar1::prepare(); // sync 1)
> Resource 2 (xar2::prepare(); // sync 2)
> Coordinator (insert(tmLog) // sync 3)
> Resource 1 (xar1::commit() // sync 4)
> Resource 2 (xar2::commit() // sync 5)
> Coordinator (delete(tmLog) // sync 6 (potentally lazy))
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1330) Extend the transaction boundary of the transaction manager embedded in a JDBC compliant database to other resources which can support two-phase commit semantics such as XAResources
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1330?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1330.
-------------------------------
> Extend the transaction boundary of the transaction manager embedded in a JDBC compliant database to other resources which can support two-phase commit semantics such as XAResources
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1330
> URL: https://issues.jboss.org/browse/JBTM-1330
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Tom Jenkinson
>
> Where you multiplex the users application table and the transaction log in the same JDBC local transaction.
> LLR
> ===
> Resource 2 provides Coordinator
> Resource1 (xar1::prepare();) // sync 1
> Resource2 (ds1::insert(tmLog)
> ds1::commit() // sync 2)
> Resource 1 (xar1::commit(); // sync 3)
> Resource 1 (ds1::delete(tmLog))
> ds1::commit() // sync 4 (potentally lazy)
> XA
> ==
> Resource 1 (xar1::prepare(); // sync 1)
> Resource 2 (xar2::prepare(); // sync 2)
> Coordinator (insert(tmLog) // sync 3)
> Resource 1 (xar1::commit() // sync 4)
> Resource 2 (xar2::commit() // sync 5)
> Coordinator (delete(tmLog) // sync 6 (potentally lazy))
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1330) Extend the transaction boundary of the transaction manager embedded in a JDBC compliant database to other resources which can support two-phase commit semantics such as XAResources
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1330?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reopened JBTM-1330:
---------------------------------
> Extend the transaction boundary of the transaction manager embedded in a JDBC compliant database to other resources which can support two-phase commit semantics such as XAResources
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1330
> URL: https://issues.jboss.org/browse/JBTM-1330
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Tom Jenkinson
>
> Where you multiplex the users application table and the transaction log in the same JDBC local transaction.
> LLR
> ===
> Resource 2 provides Coordinator
> Resource1 (xar1::prepare();) // sync 1
> Resource2 (ds1::insert(tmLog)
> ds1::commit() // sync 2)
> Resource 1 (xar1::commit(); // sync 3)
> Resource 1 (ds1::delete(tmLog))
> ds1::commit() // sync 4 (potentally lazy)
> XA
> ==
> Resource 1 (xar1::prepare(); // sync 1)
> Resource 2 (xar2::prepare(); // sync 2)
> Coordinator (insert(tmLog) // sync 3)
> Resource 1 (xar1::commit() // sync 4)
> Resource 2 (xar2::commit() // sync 5)
> Coordinator (delete(tmLog) // sync 6 (potentally lazy))
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1051) Detect when standalone-xts.xml falls out of sync
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1051?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1051.
---------------------------------
Resolution: Deferred
not closing deferred issues
> Detect when standalone-xts.xml falls out of sync
> ------------------------------------------------
>
> Key: JBTM-1051
> URL: https://issues.jboss.org/browse/JBTM-1051
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Paul Robinson
> Assignee: Paul Robinson
>
> We've been having a problem with updates being made to standalone-full.xml and not being applied to standalone-xts.xml. Most of the time this causes no obvious problem to us, but clearly will cause a problem for our users. If they try to use XTS in conjunction with some other technology, such as JMS, that requires a change to the server config, they will hit problems. However, other times this problem is more obvious as it can prevent the AS from booting or produce errors.
> In the long term, we aim to have a better solution to this multiple server config issue. In the short term we need to detect when these files fall out of sync and then create a pull request to fix it.
> On failure of the job, we can then fix it manually by:
> # Overwriting standalone-xts.xml with standalone-full.xml.
> # Adding the '<extension module="org.jboss.as.xts"/>' line back in
> # Adding the '<subsystem xmlns="urn:jboss:domain:xts:1.0">' block back in.
> # Jira the problem in the AS7 jira project and name the issue "standalone-xts.xml fallen out of sync with standalone-full.xml" (Essential for demonstrating to the AS7 team that this is a problem)
> # Create a pull request to resolve the issue.
> We need an automated way of detecting this problem, so that it can be fixed ASAP.
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1051) Detect when standalone-xts.xml falls out of sync
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1051?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reopened JBTM-1051:
---------------------------------
> Detect when standalone-xts.xml falls out of sync
> ------------------------------------------------
>
> Key: JBTM-1051
> URL: https://issues.jboss.org/browse/JBTM-1051
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Paul Robinson
> Assignee: Paul Robinson
>
> We've been having a problem with updates being made to standalone-full.xml and not being applied to standalone-xts.xml. Most of the time this causes no obvious problem to us, but clearly will cause a problem for our users. If they try to use XTS in conjunction with some other technology, such as JMS, that requires a change to the server config, they will hit problems. However, other times this problem is more obvious as it can prevent the AS from booting or produce errors.
> In the long term, we aim to have a better solution to this multiple server config issue. In the short term we need to detect when these files fall out of sync and then create a pull request to fix it.
> On failure of the job, we can then fix it manually by:
> # Overwriting standalone-xts.xml with standalone-full.xml.
> # Adding the '<extension module="org.jboss.as.xts"/>' line back in
> # Adding the '<subsystem xmlns="urn:jboss:domain:xts:1.0">' block back in.
> # Jira the problem in the AS7 jira project and name the issue "standalone-xts.xml fallen out of sync with standalone-full.xml" (Essential for demonstrating to the AS7 team that this is a problem)
> # Create a pull request to resolve the issue.
> We need an automated way of detecting this problem, so that it can be fixed ASAP.
--
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
11 years, 2 months