[JBoss JIRA] (JBTM-2182) [quickstart] NoClassDefFoundError on ArjunaJTA/maven
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2182?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2182:
----------------------------------------
My recommendation is to go through each pom and explicitly add the missing dependencies. This would keep the examples self contained and make it easy for the user to figure out what the dependencies are.
> [quickstart] NoClassDefFoundError on ArjunaJTA/maven
> ----------------------------------------------------
>
> Key: JBTM-2182
> URL: https://issues.jboss.org/browse/JBTM-2182
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Andrew Rubinger
> Assignee: Tom Jenkinson
> Fix For: 5.0.3
>
>
> [INFO] --- exec-maven-plugin:1.2:exec (default-cli) @ maven ---
> Exception in thread "main" java.lang.RuntimeException: java.lang.NoClassDefFoundError: Ljavax/transaction/TransactionManager;
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:81)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
> at com.arjuna.ats.jta.common.jtaPropertyManager.getJTAEnvironmentBean(jtaPropertyManager.java:42)
> at com.arjuna.ats.jta.TransactionManager.transactionManager(TransactionManager.java:71)
> at TransactionManagerExample.main(TransactionManagerExample.java:39)
> Caused by: java.lang.NoClassDefFoundError: Ljavax/transaction/TransactionManager;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2570)
> at java.lang.Class.getDeclaredFields(Class.java:1903)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:135)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:78)
> ... 4 more
> Caused by: java.lang.ClassNotFoundException: javax.transaction.TransactionManager
> at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 9 more
> Probably due to Tx API being in provided scope, not included in exec:exec under src/java/main?
> [INFO] +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:provided
> Also: NCDFE in javax_transaction/TransactionExample:
> Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logging/Logger
> Probably wanna audit the whole module; is this not tested in CI? Would suggest re-implementing perhaps as unit tests instead of Main classes.
> From Mike: It gets run under CI regularly (and the last build was on 22-May-2014 16:13:23). I can't remember the last time it failed. You should be able to just check out the repo and type mvn clean install from the top
> From Tom: I said that we might not run exec:exec in CI as some of the QS are quite intricate and difficult to script.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2183:
-------------------------------------
Thanks Mike, that makes sense. A good approach. It might be useful still if the user doesn't want such a power user option but we can wait for customer request for that.
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2183:
----------------------------------------
After consultation with Jonathan I have downgraded the priority to optional. The recommendation is make sure that the recovery credentials on a connection are configured correctly:
- set the recovery-username and recovery-password attributes to have sufficient privileges to access the oracle transaction tables
- if multiple datasources are configured against the same database make sure that only one of them is enabled for recovery (by setting the boolean attribute no-recovery="true|false").
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2183:
-----------------------------------
Priority: Optional (was: Major)
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2183:
-------------------------------------
Ondra has confirmed it is a new test, I have asked for a list of versions of Oracle which it affects. I can accept it as a requirement that the user committing a branch should have write access the tables.
To be clear, this affects the scenario where you have multiple data sources accessing the same database with different credentials.
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2183:
-------------------------------------
I think its that the EAP test suite now tests this and didn't before. It does sort of make sense that the user to commit has to have permissions on those tables. Maybe we could say the recovery user needs permissions on all the tables? but then we would need some additional config to indicate a recovery user.
I will double check with Ondra that its not a regression.
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
Mark Little edited comment on JBTM-2183 at 5/25/14 2:15 PM:
------------------------------------------------------------
Have we seen this behaviour elsewhere in the past? I don't recall it. A change in Oracle? Or just lucky for us so far not to have seen it?
As to changing the default, we can't do that until the EAP 7 timeframe even if we wanted to. Plus, we'd better be able to show that this has no impact on performance, reliability etc. in environments where the RM doesn't exhibit this behaviour. Otherwise may be best to err on the side of caution and perhaps catch the error in recovery and swap in the alternate behaviour for the next sweep.
was (Author: marklittle):
Have we seen this behaviour elsewhere in the past? I don't recall it.
As to changing the default, we can't do that until the EAP 7 timeframe.
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2183:
-----------------------------------
Have we seen this behaviour elsewhere in the past? I don't recall it.
As to changing the default, we can't do that until the EAP 7 timeframe.
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBTM-2183:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075008
> Need finer grained control over which XAResource is used for recovery
> ---------------------------------------------------------------------
>
> Key: JBTM-2183
> URL: https://issues.jboss.org/browse/JBTM-2183
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.20, 5.0.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.21, 5.0.2
>
>
> During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
> However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
> The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
> And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2183:
--------------------------------------
Summary: Need finer grained control over which XAResource is used for recovery
Key: JBTM-2183
URL: https://issues.jboss.org/browse/JBTM-2183
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Recovery
Affects Versions: 5.0.1, 4.17.20
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 4.17.21, 5.0.2
During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery.
However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user".
The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) .
And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months