June 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1754) Make project names consistent in poms

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1754?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1754: ------------------------------------- Hi Weinan, I think that would be best, if you didn't mind? Thanks, Tom > Make project names consistent in poms > ------------------------------------- > > Key: JBTM-1754 > URL: https://issues.jboss.org/browse/JBTM-1754 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Paul Gier > Assignee: Paul Gier > Fix For: 5.0.0.M4 > > > The project names used in the build are not consistent which makes it difficult for someone unfamiliar with the project to debug build issues. > Some examples are provided: > ||Dir Name||Artifact ID||Project Name||Proposed Name|| > |/ArjunaJTA|narayana-jta-all|JBoss JTA everything|Narayana: ArjunaJTA| > |/ArjunaJTS/narayana-jts-idlj|narayana-jts-idlj|JBossJTS packaged module with idlj stubs|Narayana: ArjunaJTS idlj| > |/ArjunaJTS/orbportability|orbportability|JBossJTS orb portability|Narayana: ArjunaJTS orbportability| > The project names can be changed without disrupting the way the build works, so these should be changed to match the dir and artifactId as much as possible. -- 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-1754) Make project names consistent in poms

by Weinan Li (JIRA)

[ https://issues.jboss.org/browse/JBTM-1754?page=com.atlassian.jira.plugin.... ] Weinan Li commented on JBTM-1754: --------------------------------- Tom, I have a question: Shall a rename the prefix from "Narayana: " to "JBossTS" for branch 4.17? > Make project names consistent in poms > ------------------------------------- > > Key: JBTM-1754 > URL: https://issues.jboss.org/browse/JBTM-1754 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Paul Gier > Assignee: Paul Gier > Fix For: 5.0.0.M4 > > > The project names used in the build are not consistent which makes it difficult for someone unfamiliar with the project to debug build issues. > Some examples are provided: > ||Dir Name||Artifact ID||Project Name||Proposed Name|| > |/ArjunaJTA|narayana-jta-all|JBoss JTA everything|Narayana: ArjunaJTA| > |/ArjunaJTS/narayana-jts-idlj|narayana-jts-idlj|JBossJTS packaged module with idlj stubs|Narayana: ArjunaJTS idlj| > |/ArjunaJTS/orbportability|orbportability|JBossJTS orb portability|Narayana: ArjunaJTS orbportability| > The project names can be changed without disrupting the way the build works, so these should be changed to match the dir and artifactId as much as possible. -- 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-1754) Make project names consistent in poms

by Weinan Li (JIRA)

[ https://issues.jboss.org/browse/JBTM-1754?page=com.atlassian.jira.plugin.... ] Weinan Li commented on JBTM-1754: --------------------------------- I'm creating the patch for 4.17 > Make project names consistent in poms > ------------------------------------- > > Key: JBTM-1754 > URL: https://issues.jboss.org/browse/JBTM-1754 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Paul Gier > Assignee: Paul Gier > Fix For: 5.0.0.M4 > > > The project names used in the build are not consistent which makes it difficult for someone unfamiliar with the project to debug build issues. > Some examples are provided: > ||Dir Name||Artifact ID||Project Name||Proposed Name|| > |/ArjunaJTA|narayana-jta-all|JBoss JTA everything|Narayana: ArjunaJTA| > |/ArjunaJTS/narayana-jts-idlj|narayana-jts-idlj|JBossJTS packaged module with idlj stubs|Narayana: ArjunaJTS idlj| > |/ArjunaJTS/orbportability|orbportability|JBossJTS orb portability|Narayana: ArjunaJTS orbportability| > The project names can be changed without disrupting the way the build works, so these should be changed to match the dir and artifactId as much as possible. -- 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-1787) Compiliation failure for BlackTie on Fedora 18

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-1787: ----------------------------------- Summary: Compiliation failure for BlackTie on Fedora 18 Key: JBTM-1787 URL: https://issues.jboss.org/browse/JBTM-1787 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: BlackTie Reporter: Tom Jenkinson Assignee: Amos Feng Fix For: 5.0.0.M4 test-compile: [mkdir] Created dir: /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes [copy] Copying 5 files to /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes [cc] 12 total files to be compiled. [cc] Starting link [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0 [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0 [cc] cpp-test-classes/TestSynchronizableObject.o:(.data.rel.ro._ZTV6Waiter[_ZTV6Waiter]+0x70): undefined reference to `ACE_Event_Handler::handle_signal(int, siginfo_t*, ucontext*)' [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' [cc] collect2: error: ld returned 1 exit status -- 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-1382) QA build does not archive test group summary files

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1382?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1382: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/200, https://github.com/jbosstm/narayana/pull/321, https://github.com/jbosstm/narayana/pull/340 (was: https://github.com/jbosstm/narayana/pull/200, https://github.com/jbosstm/narayana/pull/321) > QA build does not archive test group summary files > -------------------------------------------------- > > Key: JBTM-1382 > URL: https://issues.jboss.org/browse/JBTM-1382 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Testing > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 4.17.5, 5.0.0.M2 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The QA test suite consists of a number of test groups. The build produces a summary file showing the status of each sub test within a group (these are called TEST-<test group>.txt and stored in the qa directory). We currently archive the qa/testoutput directory but it would be useful to also archive these summary text files. Note that we cannot rely on Jenkins to do this for us since the jts remote test group is executed twice (once for each orb) and the files from the first run are overwritten. -- 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-1783) no matching injection point in ArjunaCore/arjuna/test/byteman-scripts/reaper.txt

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1783?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-1783: ---------------------------- Summary: no matching injection point in ArjunaCore/arjuna/test/byteman-scripts/reaper.txt (was: byteman warning messages in ArjunaCore/arjuna/test/byteman-scripts/reaper.txt ) > no matching injection point in ArjunaCore/arjuna/test/byteman-scripts/reaper.txt > --------------------------------------------------------------------------------- > > Key: JBTM-1783 > URL: https://issues.jboss.org/browse/JBTM-1783 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.0.M4 > > Original Estimate: 3 days > Time Spent: 2 hours > Remaining Estimate: 2 days, 6 hours > > {noformat} > [INFO] Checking 3 byteman scripts in /home/zhfeng/src/zhfeng/narayana/ArjunaCore/arjuna/target/test-classes > [WARNING] WARNING : Warning type checking rule "pause transaction reaper 3" loaded from /home/zhfeng/src/zhfeng/narayana/ArjunaCore/arjuna/target/test-classes/reaper.txt line 65 against method check() void > org.jboss.byteman.rule.exception.TypeWarningException: no matching injection point for method check() void > [WARNING] WARNING : Warning type checking rule "pause transaction reaper 3" loaded from /home/zhfeng/src/zhfeng/narayana/ArjunaCore/arjuna/target/test-classes/reaper.txt line 65 > org.jboss.byteman.rule.exception.TypeWarningException: failed to find any matching trigger method in class com.arjuna.ats.arjuna.coordinator.TransactionReaper > [WARNING] WARNING : Warning type checking rule "pause transaction reaper 4" loaded from /home/zhfeng/src/zhfeng/narayana/ArjunaCore/arjuna/target/test-classes/reaper.txt line 79 against method check() void > org.jboss.byteman.rule.exception.TypeWarningException: no matching injection point for method check() void > [WARNING] WARNING : Warning type checking rule "pause transaction reaper 4" loaded from /home/zhfeng/src/zhfeng/narayana/ArjunaCore/arjuna/target/test-classes/reaper.txt line 79 > org.jboss.byteman.rule.exception.TypeWarningException: failed to find any matching trigger method in class com.arjuna.ats.arjuna.coordinator.TransactionReaper > [WARNING] WARNING : Warning type checking rule "pause transaction reaper worker 4" loaded from /home/zhfeng/src/zhfeng/narayana/ArjunaCore/arjuna/target/test-classes/reaper.txt line 186 against method doCancellations() void > org.jboss.byteman.rule.exception.TypeWarningException: no matching injection point for method doCancellations() void > [WARNING] WARNING : Warning type checking rule "pause transaction reaper worker 4" loaded from /home/zhfeng/src/zhfeng/narayana/ArjunaCore/arjuna/target/test-classes/reaper.txt line 186 > org.jboss.byteman.rule.exception.TypeWarningException: failed to find any matching trigger method in class com.arjuna.ats.arjuna.coordinator.TransactionReaper > {noformat} -- 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-715) Improve test coverage for jts

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-715?page=com.atlassian.jira.plugin.s... ] Work on JBTM-715 started by Mark Little. > Improve test coverage for jts > ----------------------------- > > Key: JBTM-715 > URL: https://issues.jboss.org/browse/JBTM-715 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTS, Testing > Reporter: Mark Little > Assignee: Mark Little > Fix For: 5.0.0.Final > > -- 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-1786) Change to TMFAIL for an ABORT on a non-prepared TX

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1786?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-1786: ----------------------------------- Updated the components associated with the issue, since we have two XAResourceRecord instances. > Change to TMFAIL for an ABORT on a non-prepared TX > -------------------------------------------------- > > Key: JBTM-1786 > URL: https://issues.jboss.org/browse/JBTM-1786 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA, JTS > Affects Versions: 4.16.4 > Reporter: Johnathon Lee > Assignee: Johnathon Lee > > An ABORT on a non-prepared TX should be calling end with TMFAIL. > It's more efficient in that the RM can return an RB* code immediately and short circuit the rollback internally if it likes. More importantly though the RM is less likely to object that it's still running tx activity on another thread and the concurrent TMSUCCESS therefore makes no sense to it. > Also the XAResourceRecord.topLevelAbort code should immediately continue on to calling rollback on the resource despite the failed end(). -- 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-1786) Change to TMFAIL for an ABORT on a non-prepared TX

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1786?page=com.atlassian.jira.plugin.... ] Mark Little updated JBTM-1786: ------------------------------ Component/s: JTS > Change to TMFAIL for an ABORT on a non-prepared TX > -------------------------------------------------- > > Key: JBTM-1786 > URL: https://issues.jboss.org/browse/JBTM-1786 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA, JTS > Affects Versions: 4.16.4 > Reporter: Johnathon Lee > Assignee: Johnathon Lee > > An ABORT on a non-prepared TX should be calling end with TMFAIL. > It's more efficient in that the RM can return an RB* code immediately and short circuit the rollback internally if it likes. More importantly though the RM is less likely to object that it's still running tx activity on another thread and the concurrent TMSUCCESS therefore makes no sense to it. > Also the XAResourceRecord.topLevelAbort code should immediately continue on to calling rollback on the resource despite the failed end(). -- 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-1776) Merge the individual emma code coverage reports

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1776?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1776. --------------------------------- Resolution: Done > Merge the individual emma code coverage reports > ----------------------------------------------- > > Key: JBTM-1776 > URL: https://issues.jboss.org/browse/JBTM-1776 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Build System, Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.M4 > > > Currently each module will generate its own code coverage report. It would be useful if we can try to work out how to get Emma to either merge the reports or potentially we can see if we can change the location of where emma generates its reports (currently the target folder of each module) to a common location and see if that will will merge the reports automatically. > The benefit of this is that certain modules do not contain complete code coverage unit tests and so we appear to have low coverage in some areas but when taken in context with the rest of the project this coverage would be much higher. > We should also attempt to get the qa/ runs to generate emma coverage data. -- 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 June 2013