July 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2704: ------------------------------------- You need to link a WFLY issue for the required WildFly changes. I don't think you should mark it resolved until the WFLY is resolved as that is the blocker. > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2704: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2704: ------------------------------------- You should document the requirement to deploy on a weld container. Just add a new section in the project docs with this note. Further docs can be added later. > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1468) Support pure-JTA client and server for WS-AT and REST-AT

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1468?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-1468: ------------------------------------- [~mmusgrov]: I think 1 is complete. IIRC, Web Service implementation classes (like: https://github.com/jbosstm/quickstart/blob/master/XTS/wsat-jta-multi_serv...) needed to be marked in some way to allow the deployment processors in the AS to correctly set up the WSAT to JTA bridging. It looks like we now figure that out a different way, as the quickstart above is not using the annotation. > Support pure-JTA client and server for WS-AT and REST-AT > -------------------------------------------------------- > > Key: JBTM-1468 > URL: https://issues.jboss.org/browse/JBTM-1468 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: REST, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.later > > Original Estimate: 2 days > Remaining Estimate: 2 days > > This allows the Client and server application to just use the JTA APIs, whilst having the distribution done over WS-AT or REST-AT. > To do this we need to: > # Remove @Transactional annotation. We then need to use some other mechanism to support the (optional) WS-AT participants that want to use annotations. > # Client side JTA->REST-AT bridge. Needs implementing. > # Server side REST-AT->JTA bridge. Needs integrating into code base. > # Update the TXBridge quickstarts to use this and move them out. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBTM-2701: ------------------------------------------ Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=1356589) Bugzilla Update: (was: Perform) > XAR should be scanned more frequently for prepared transactions > --------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBTM-2701: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1356589 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1356589, https://bugzilla.redhat.com/show_bug.cgi?id=1360648) > XAR should be scanned more frequently for prepared transactions > --------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2709: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1035 > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBTM-2701: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1356589, https://bugzilla.redhat.com/show_bug.cgi?id=1360648 Bugzilla Update: Perform > XAR should be scanned more frequently for prepared transactions > --------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2709: -------------------------------- Fix Version/s: 5.next > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2709: -------------------------------- Issue Type: Bug (was: Task) > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues July 2016