May 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1689) "jta" vs. "jts" profile seems duplicate

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1689?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1689: ------------------------------------- I would be happy to remove: all, core, jta, jts, jts-idlj and stm from /pom.xml [~marklittle] does use "mvn install -Pstm", but perhaps he will be happy to use: "mvn install -pl STM -am" instead? Leave it with me and I will raise the pull request if Mark is happy to stop using the profile. For completeness, this is what would be replaced: all (as used in EAP builds) = mvn install core = mvn install -am -pl ArjunaCore/arjunacore jta = mvn install -am -pl ArjunaJTA/narayana-jta jts = mvn install -am -pl ArjunaJTS/narayana-jts-jacorb jts-idlj = mvn install -am -pl ArjunaJTS/narayana-jts-idlj -Didlj-enabled=true stm = mvn install -am -pl stm > "jta" vs. "jts" profile seems duplicate > --------------------------------------- > > Key: JBTM-1689 > URL: https://issues.jboss.org/browse/JBTM-1689 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build System > Affects Versions: 4.17.4 > Reporter: Weinan Li > Assignee: Tom Jenkinson > Priority: Minor > > "jta" vs. "jts" profile, they seem to build the same modules except for ArjunaJTS. > As maven has some built in options for selecting which modules/directories to build, would it be better to just use those options? Instead of defining profiles, it might look something like "mvn install -pl common,ArjunaCore" instead of the build profile "mvn install -Pcore" -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1689) "jta" vs. "jts" profile seems duplicate

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/JBTM-1689?page=com.atlassian.jira.plugin.... ] Paul Gier commented on JBTM-1689: --------------------------------- Which profiles do your team regularly use? I guess we should keep just the most commonly used ones? > "jta" vs. "jts" profile seems duplicate > --------------------------------------- > > Key: JBTM-1689 > URL: https://issues.jboss.org/browse/JBTM-1689 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build System > Affects Versions: 4.17.4 > Reporter: Weinan Li > Assignee: Tom Jenkinson > Priority: Minor > > "jta" vs. "jts" profile, they seem to build the same modules except for ArjunaJTS. > As maven has some built in options for selecting which modules/directories to build, would it be better to just use those options? Instead of defining profiles, it might look something like "mvn install -pl common,ArjunaCore" instead of the build profile "mvn install -Pcore" -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1694) Use emma jar from a Maven repo instead of checking into the build

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/JBTM-1694?page=com.atlassian.jira.plugin.... ] Paul Gier updated JBTM-1694: ---------------------------- Summary: Use emma jar from a Maven repo instead of checking into the build (was: upload orson and emma to repository.jboss.org) Description: Currently in /pom.xml: {code} <systemPath>${emma.jar.location}</systemPath> {code} was: Currently in ArjunaCore/arjuna/pom.xml: {code} <systemPath>${orson.jar.location}/../qa/dbdrivers/jConnect-6_0/classes/jconn3.jar</systemPath> {code} And user need to download orson.jar from internet and set orson jar location manually. Is it okay that we upload the jars to repository.jboss.org? Changed issue title and description to focus on emma, since there is another issue (JBTM-1671) for orson. > Use emma jar from a Maven repo instead of checking into the build > ----------------------------------------------------------------- > > Key: JBTM-1694 > URL: https://issues.jboss.org/browse/JBTM-1694 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Weinan Li > Assignee: Tom Jenkinson > Fix For: 4.17.5, 5.0.0.M3 > > > Currently in /pom.xml: > {code} > <systemPath>${emma.jar.location}</systemPath> > {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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1694) upload orson and emma to repository.jboss.org

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/JBTM-1694?page=com.atlassian.jira.plugin.... ] Paul Gier commented on JBTM-1694: --------------------------------- {quote} we are using a custom fork but only for community testing {quote} That's what our thirdparty-releases repository [1] is for, so ideally we should upload the patched release there. Were the patches also submitted to upstream emma so they can get into a future release? Moving the emma tests to a profile would be good. [1]https://community.jboss.org/wiki/MavenDeployingaThirdpartyRelease > upload orson and emma to repository.jboss.org > --------------------------------------------- > > Key: JBTM-1694 > URL: https://issues.jboss.org/browse/JBTM-1694 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Weinan Li > Assignee: Tom Jenkinson > Fix For: 4.17.5, 5.0.0.M3 > > > Currently in ArjunaCore/arjuna/pom.xml: > {code} > <systemPath>${orson.jar.location}/../qa/dbdrivers/jConnect-6_0/classes/jconn3.jar</systemPath> > {code} > And user need to download orson.jar from internet and set orson jar location manually. Is it okay that we upload the jars to repository.jboss.org? -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1695) Change the 'common' module to use the normal maven convention for source layout.

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1695?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1695: ------------------------------------- Agreed, I will leave it unscheduled (rather than defer) for now and assign it to myself > Change the 'common' module to use the normal maven convention for source layout. > -------------------------------------------------------------------------------- > > Key: JBTM-1695 > URL: https://issues.jboss.org/browse/JBTM-1695 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.17.4 > Reporter: Weinan Li > Assignee: Weinan Li > Priority: Minor > > The common module doesn't use the normal maven convention for source layout. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1695) Change the 'common' module to use the normal maven convention for source layout.

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1695?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-1695: ----------------------------------- Assignee: Tom Jenkinson (was: Weinan Li) > Change the 'common' module to use the normal maven convention for source layout. > -------------------------------------------------------------------------------- > > Key: JBTM-1695 > URL: https://issues.jboss.org/browse/JBTM-1695 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.17.4 > Reporter: Weinan Li > Assignee: Tom Jenkinson > Priority: Minor > > The common module doesn't use the normal maven convention for source layout. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1695) Change the 'common' module to use the normal maven convention for source layout.

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/JBTM-1695?page=com.atlassian.jira.plugin.... ] Paul Gier commented on JBTM-1695: --------------------------------- Eventually, I think it would be good to change them all, but I think it's fine to defer this one for now. > Change the 'common' module to use the normal maven convention for source layout. > -------------------------------------------------------------------------------- > > Key: JBTM-1695 > URL: https://issues.jboss.org/browse/JBTM-1695 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.17.4 > Reporter: Weinan Li > Assignee: Weinan Li > Priority: Minor > > The common module doesn't use the normal maven convention for source layout. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1708) readme instructions for starting the standalone transaction manager are incorrect

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-1708: -------------------------------------- Summary: readme instructions for starting the standalone transaction manager are incorrect Key: JBTM-1708 URL: https://issues.jboss.org/browse/JBTM-1708 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.17.4 Reporter: Michael Musgrove Assignee: Michael Musgrove The instructions in ./narayana-full/readme.txt for starting the transaction manager don't work. Also the script for starting the TM only starts the JTS version. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1707) JBTM-377 not able to download patch 4.4.CR2, 4.2.3.CP09 for jboss version 4.2.3.GA

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1707?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1707. --------------------------------- Resolution: Rejected Please use our forum to ask questions: https://community.jboss.org/en/jbosstm/?view=discussions PS, downloads here: https://www.jboss.org/jbosstm/downloads Go for the latest .Final you can is my suggestion > JBTM-377 not able to download patch 4.4.CR2, 4.2.3.CP09 for jboss version 4.2.3.GA > ------------------------------------------------------------------------------------- > > Key: JBTM-1707 > URL: https://issues.jboss.org/browse/JBTM-1707 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Recovery > Environment: JBoss 4.2.3.GA > Reporter: Sube Singh > Assignee: Tom Jenkinson > Labels: jboss > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > We are facing "WARN [arjLoggerI18N] [com.arjuna.ats.internal.arjuna.gandiva.inventory...." issue. To fix it we got to know about patch "4.4.CR2, 4.2.3.CP09" from url "https://issues.jboss.org/browse/JBTM-377" but did not find web-link to download the same patch. > Please also suggest do we have to apply this patch or go for higher version of jboss that has fix of above discussed problem. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1702: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 4.17.5 5.0.0.M3 Resolution: Done > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.5, 5.0.0.M3 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- 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

10 years, 11 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 May 2013