April 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2887) No warnings if a field marked with @State is not a supported datatype

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2887?page=com.atlassian.jira.plugin.... ] Michael Musgrove reassigned JBTM-2887: -------------------------------------- Assignee: Michael Musgrove (was: Mark Little) > No warnings if a field marked with @State is not a supported datatype > --------------------------------------------------------------------- > > Key: JBTM-2887 > URL: https://issues.jboss.org/browse/JBTM-2887 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.5.24.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > If a field annotated with @State (such as a map) is not one of the supported datatypes then any attempt to obtain an STM lock will fail with LockResult.REFUSED. > It would be useful if a warning is logged to indicate why lock acquisition is refused to prompt the developer to override the save_state and restore_state methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2887) No warnings if a field marked with @State is not a supported datatype

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2887?page=com.atlassian.jira.plugin.... ] Michael Musgrove reassigned JBTM-2887: -------------------------------------- Assignee: Mark Little (was: Michael Musgrove) > No warnings if a field marked with @State is not a supported datatype > --------------------------------------------------------------------- > > Key: JBTM-2887 > URL: https://issues.jboss.org/browse/JBTM-2887 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.5.24.Final > Reporter: Michael Musgrove > Assignee: Mark Little > > If a field annotated with @State (such as a map) is not one of the supported datatypes then any attempt to obtain an STM lock will fail with LockResult.REFUSED. > It would be useful if a warning is logged to indicate why lock acquisition is refused to prompt the developer to override the save_state and restore_state methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2887) No warnings if a field marked with @State is not a supported datatype

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2887?page=com.atlassian.jira.plugin.... ] Michael Musgrove reassigned JBTM-2887: -------------------------------------- Assignee: Michael Musgrove (was: Mark Little) > No warnings if a field marked with @State is not a supported datatype > --------------------------------------------------------------------- > > Key: JBTM-2887 > URL: https://issues.jboss.org/browse/JBTM-2887 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.5.24.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > If a field annotated with @State (such as a map) is not one of the supported datatypes then any attempt to obtain an STM lock will fail with LockResult.REFUSED. > It would be useful if a warning is logged to indicate why lock acquisition is refused to prompt the developer to override the save_state and restore_state methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2891) Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2891?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka edited comment on JBTM-2891 at 4/26/17 6:41 AM: ---------------------------------------------------------------- I was already experimenting with this a little bit based on my fix for the quickstart (WFLY-8592) but I found that method {{getAllKnownImplementors}} does not consider interface inheritance. Thus for the hierarchy structure is like {code} (deployment class) -> com.arjuna.wst.Durable2PCParticipant/Volatile2PCParticipant -> com.arjuna.wst.Participant. {code} call {code} compositeIndex.getAllKnownImplementors(DotName.createSimple(com.arjuna.wst.Participant.class.getName())) {code} returns nothing. I discussed this with Jason and it's expected behavior and he suggested two ways (quoting him) {quote} There are two solutions I can think of to this A) Human hard coding of the Naryana inheritance hierarchy of that interface into the XTS deployer - assumes that it changes infrequently, or is it least done via a component update of Naryana B) A small custom maven plugin in the wildfly build for the transaction subsystem that generates Java source or a data file that achieves whats described in A) that can be called by the subsystem code. In the case of Java code, the subsystem code would just refer to a base type or an interface, and then dynamically load the generated implementation class. The maven plugin could use Jandex, some other bytecode analysis framework, or even Java reflection to discover the relevant types. {quote} I think that the option {{A}} is easier and expected one. The interfaces is not expected to be changed. was (Author: ochaloup): I was already experimenting with this a little bit based on my fix for the quickstart (WFLY-8592) but I found that method {{getAllKnownImplementors}} does not consider interface inheritance. Thus for the hierarchy structure is like {code} (deployment class) -> com.arjuna.wst.Durable2PCParticipant/Volatile2PCParticipant -> com.arjuna.wst.Participant. {code} call {code} compositeIndex.getAllKnownImplementors(DotName.createSimple(com.arjuna.wst.Participant.class.getName())) {code} returns nothing. I discussed this with Jason and it's expected behavior and he suggested two ways (quoting him) {quote} There are two solutions I can think of to this A) Human hard coding of the Naryana inheritance hierarchy of that interface into the XTS deployer - Assumes that it changes infrequently, or is it least done via a component update of Naryana B) A small custom maven plugin in the wildfly build for the transaction subsystem that generates Java source or a data file that achieves whats described in A) that can be called by the subsystem code. In the case of Java code, the subsystem code would just refer to a base type or an interface, and then dynamically load the generated implementation class. The maven plugin could use Jandex, some other bytecode analysis framework, or even Java reflection to discover the relevant types. {quote} I think that the option {{A}} is easier and expected one. The interfaces is not expected to be changed. > Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces > -------------------------------------------------------------------------------------------- > > Key: JBTM-2891 > URL: https://issues.jboss.org/browse/JBTM-2891 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > WildFly currently adds default dependency for {{org.jboss.xts}} module when deployment defines some of the compensations annotation. Provided by {{XTSDependenciesDeploymentProcessor}} see https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jbos... (in fact XTS dependency is needed only when compensating framework works in distributed manner but it's absolutely ok by my point of view to add the dependency as it's currently done). > But if deployment uses just XTS interfaces and defines WS handlers in descriptor then user is forced to apply the dependency on its own. > E.g. eap quickstarts does so > https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/java... > It implements Durable2PCParticipant and the XTS transaction context processing is done by specifying the xts handler in descriptor (https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/weba...). > It would be good to add implicit dependency in such cases for user does not need to provide it on his own. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2891) Default dependency on org.jboss.xts could be added to WFLY deployements when deployment uses XTS interfaces

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2891?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2891: ---------------------------------- Summary: Default dependency on org.jboss.xts could be added to WFLY deployements when deployment uses XTS interfaces (was: Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces) > Default dependency on org.jboss.xts could be added to WFLY deployements when deployment uses XTS interfaces > ----------------------------------------------------------------------------------------------------------- > > Key: JBTM-2891 > URL: https://issues.jboss.org/browse/JBTM-2891 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > WildFly currently adds default dependency for {{org.jboss.xts}} module when deployment defines some of the compensations annotation. Provided by {{XTSDependenciesDeploymentProcessor}} see https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jbos... (in fact XTS dependency is needed only when compensating framework works in distributed manner but it's absolutely ok by my point of view to add the dependency as it's currently done). > But if deployment uses just XTS interfaces and defines WS handlers in descriptor then user is forced to apply the dependency on its own. > E.g. eap quickstarts does so > https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/java... > It implements Durable2PCParticipant and the XTS transaction context processing is done by specifying the xts handler in descriptor (https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/weba...). > It would be good to add implicit dependency in such cases for user does not need to provide it on his own. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2891) Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2891?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-2891: --------------------------------------- I was already experimenting with this a little bit based on my fix for the quickstart (WFLY-8592) but I found that method {{getAllKnownImplementors}} does not consider interface inheritance. Thus for the hierarchy structure is like {code} (deployment class) -> com.arjuna.wst.Durable2PCParticipant/Volatile2PCParticipant -> com.arjuna.wst.Participant. {code} call {code} compositeIndex.getAllKnownImplementors(DotName.createSimple(com.arjuna.wst.Participant.class.getName())) {code} returns nothing. I discussed this with Jason and it's expected behavior and he suggested two ways (quoting him) {quote} There are two solutions I can think of to this A) Human hard coding of the Naryana inheritance hierarchy of that interface into the XTS deployer - Assumes that it changes infrequently, or is it least done via a component update of Naryana B) A small custom maven plugin in the wildfly build for the transaction subsystem that generates Java source or a data file that achieves whats described in A) that can be called by the subsystem code. In the case of Java code, the subsystem code would just refer to a base type or an interface, and then dynamically load the generated implementation class. The maven plugin could use Jandex, some other bytecode analysis framework, or even Java reflection to discover the relevant types. {quote} I think that the option {{A}} is easier and expected one. The interfaces is not expected to be changed. > Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces > -------------------------------------------------------------------------------------------- > > Key: JBTM-2891 > URL: https://issues.jboss.org/browse/JBTM-2891 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > WildFly currently adds default dependency for {{org.jboss.xts}} module when deployment defines some of the compensations annotation. Provided by {{XTSDependenciesDeploymentProcessor}} see https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jbos... (in fact XTS dependency is needed only when compensating framework works in distributed manner but it's absolutely ok by my point of view to add the dependency as it's currently done). > But if deployment uses just XTS interfaces and defines WS handlers in descriptor then user is forced to apply the dependency on its own. > E.g. eap quickstarts does so > https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/java... > It implements Durable2PCParticipant and the XTS transaction context processing is done by specifying the xts handler in descriptor (https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/weba...). > It would be good to add implicit dependency in such cases for user does not need to provide it on his own. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2891) Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2891: ------------------------------------- Summary: Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces Key: JBTM-2891 URL: https://issues.jboss.org/browse/JBTM-2891 Project: JBoss Transaction Manager Issue Type: Enhancement Components: XTS Affects Versions: 5.5.24.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka WildFly currently adds default dependency for {{org.jboss.xts}} module when deployment defines some of the compensations annotation. Provided by {{XTSDependenciesDeploymentProcessor}} see https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jbos... (in fact XTS dependency is needed only when compensating framework works in distributed manner but it's absolutely ok by my point of view to add the dependency as it's currently done). But if deployment uses just XTS interfaces and defines WS handlers in descriptor then user is forced to apply the dependency on its own. E.g. eap quickstarts does so https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/java... It implements Durable2PCParticipant and the XTS transaction context processing is done by specifying the xts handler in descriptor (https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/weba...). It would be good to add implicit dependency in such cases for user does not need to provide it on his own. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2890) asyncAfterSynchronization throw exception when transaction abort

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2890?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Tom Jenkinson created pull request #1172 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > asyncAfterSynchronization throw exception when transaction abort > ---------------------------------------------------------------- > > Key: JBTM-2890 > URL: https://issues.jboss.org/browse/JBTM-2890 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.0.Final, 5.5.24.Final > Reporter: Colin Song > > *The problem:* > There's two problems about asyncAfterSynchronization(com.arjuna.ats.arjuna.coordinator.asyncAfterSynchronization=true) option: > * If we want asyncAfterSynchronization, we must set asyncBeforeSynchronization > * When tx abort, and we have asyncAfterSynchronization option, there's exception > *Root cause:* {{TwoPhaseCoordinator.synchronizationCompletionService}} and {{TwoPhaseCoordinator.runningSynchronizations}} only inited in {{asyncBeforeSynchronization}} > *Solution:* > Also init {{TwoPhaseCoordinator.synchronizationCompletionService}} and {{TwoPhaseCoordinator.runningSynchronizations}} in asyncAfterSynchronization -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2890) asyncAfterSynchronization throw exception when transaction abort

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2890?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2890: ------------------------------------- Thanks for the report - PR raised https://github.com/jbosstm/narayana/pull/1172 > asyncAfterSynchronization throw exception when transaction abort > ---------------------------------------------------------------- > > Key: JBTM-2890 > URL: https://issues.jboss.org/browse/JBTM-2890 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.0.Final, 5.5.24.Final > Reporter: Colin Song > > *The problem:* > There's two problems about asyncAfterSynchronization(com.arjuna.ats.arjuna.coordinator.asyncAfterSynchronization=true) option: > * If we want asyncAfterSynchronization, we must set asyncBeforeSynchronization > * When tx abort, and we have asyncAfterSynchronization option, there's exception > *Root cause:* {{TwoPhaseCoordinator.synchronizationCompletionService}} and {{TwoPhaseCoordinator.runningSynchronizations}} only inited in {{asyncBeforeSynchronization}} > *Solution:* > Also init {{TwoPhaseCoordinator.synchronizationCompletionService}} and {{TwoPhaseCoordinator.runningSynchronizations}} in asyncAfterSynchronization -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2890) asyncAfterSynchronization throw exception when transaction abort

by Colin Song (JIRA)

Colin Song created JBTM-2890: -------------------------------- Summary: asyncAfterSynchronization throw exception when transaction abort Key: JBTM-2890 URL: https://issues.jboss.org/browse/JBTM-2890 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.5.24.Final, 5.5.0.Final Reporter: Colin Song *The problem:* There's two problems about asyncAfterSynchronization(com.arjuna.ats.arjuna.coordinator.asyncAfterSynchronization=true) option: * If we want asyncAfterSynchronization, we must set asyncBeforeSynchronization * When tx abort, and we have asyncAfterSynchronization option, there's exception *Root cause:* {{TwoPhaseCoordinator.synchronizationCompletionService}} and {{TwoPhaseCoordinator.runningSynchronizations}} only inited in {{asyncBeforeSynchronization}} *Solution:* Also init {{TwoPhaseCoordinator.synchronizationCompletionService}} and {{TwoPhaseCoordinator.runningSynchronizations}} in asyncAfterSynchronization -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 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 April 2017