October 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3069) XTS over SSL Quickstart failed

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3069?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #238 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > XTS over SSL Quickstart failed > ------------------------------ > > Key: JBTM-3069 > URL: https://issues.jboss.org/browse/JBTM-3069 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing, XTS > Reporter: Amos Feng > Assignee: Ondra Chaloupka > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3069) XTS over SSL Quickstart failed

by Amos Feng (Jira)

Amos Feng created JBTM-3069: ------------------------------- Summary: XTS over SSL Quickstart failed Key: JBTM-3069 URL: https://issues.jboss.org/browse/JBTM-3069 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing, XTS Reporter: Amos Feng Assignee: Ondra Chaloupka -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3068) Byteman can not submit or remove the scripts when running TestCommitMarkableResourceFailActivate

by Amos Feng (Jira)

Amos Feng created JBTM-3068: ------------------------------- Summary: Byteman can not submit or remove the scripts when running TestCommitMarkableResourceFailActivate Key: JBTM-3068 URL: https://issues.jboss.org/browse/JBTM-3068 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA, Testing Reporter: Amos Feng Assignee: Amos Feng {code} [ERROR] testFailAfterPrepare(com.hp.mwtests.ts.jta.commitmarkable.TestCommitMarkableResourceFailActivate) Time elapsed: 2.782 s <<< ERROR! java.lang.Exception: The remote byteman agent reported an error: ERROR failed to find loaded rule with name Fail first phase2Commit ERROR failed to find loaded rule with name Return not inflight ERROR No rule scripts to remove at org.jboss.byteman.agent.submit.Submit$Comm.readResponse(Submit.java:966) at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:790) at org.jboss.byteman.agent.submit.Submit.deleteScripts(Submit.java:697) at org.jboss.byteman.agent.submit.Submit.deleteRulesFromFiles(Submit.java:649) at org.jboss.byteman.contrib.bmunit.BMUnit.unloadScriptFile(BMUnit.java:259) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:296) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143) {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3067) Build and run the narayana with JDK-11

by Amos Feng (Jira)

Amos Feng created JBTM-3067: ------------------------------- Summary: Build and run the narayana with JDK-11 Key: JBTM-3067 URL: https://issues.jboss.org/browse/JBTM-3067 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Reporter: Amos Feng Assignee: Amos Feng The jdk-11 could be downloaded from https://jdk.java.net/11/ and the most important feature that impacts us is [JEP 320: Remove the Java EE and CORBA Modules|https://openjdk.java.net/jeps/320] The CI job is http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-11/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2824) Check that the changes for JDK-9 support still build with JDK-8

by Amos Feng (Jira)

[ https://issues.jboss.org/browse/JBTM-2824?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-2824: --------------------------------- [~mmusgrov] I think this issue could be marked as closed since we have merged the PR for the jdk9 ? > Check that the changes for JDK-9 support still build with JDK-8 > --------------------------------------------------------------- > > Key: JBTM-2824 > URL: https://issues.jboss.org/browse/JBTM-2824 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.later > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > JBTM-2685 is adding support for building with the JDK-9 compiler using branch https://github.com/jbosstm/narayana/tree/jdk9-experimental > This JIRA is for reporting when the branch fails to build on JDK-8 (currently it is failing because the build is not producing the jar artefact for org.jboss.narayana.jts:narayana-jts-idlj). See CI job http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-9-jdk-8 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2796) Investigate the Tomcat integration tests failure with the JDK 9

by Amos Feng (Jira)

[ https://issues.jboss.org/browse/JBTM-2796?page=com.atlassian.jira.plugin.... ] Amos Feng closed JBTM-2796. --------------------------- Resolution: Done > Investigate the Tomcat integration tests failure with the JDK 9 > --------------------------------------------------------------- > > Key: JBTM-2796 > URL: https://issues.jboss.org/browse/JBTM-2796 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Application Server Integration, Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Major > Labels: jdk9 > > Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3063) Include a simple LRA quickstart showing difference between using a proxy and CDI

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3063?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #235 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Include a simple LRA quickstart showing difference between using a proxy and CDI > -------------------------------------------------------------------------------- > > Key: JBTM-3063 > URL: https://issues.jboss.org/browse/JBTM-3063 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Participants can join LRAs either via [annotations|https://github.com/eclipse/microprofile-lra/tree/master/api/s...] or via [a registration API|https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/...]. There should be a simple quickstart that demonstrates the difference between the two options. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3066) Starting a nested LRA via the client API leaves the parent as the current context

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3066?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1372 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Starting a nested LRA via the client API leaves the parent as the current context > --------------------------------------------------------------------------------- > > Key: JBTM-3066 > URL: https://issues.jboss.org/browse/JBTM-3066 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If an LRA is associated with a thread and that thread then starts a new LRA then the new one is nested under the first. When using the LRAClient API to start the child LRA the resulting context is left as the parent. This is wrong since the thread should now operate in the context of the nested LRA. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3066) Starting a nested LRA via the client API leaves the parent as the current context

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3066: -------------------------------------- Summary: Starting a nested LRA via the client API leaves the parent as the current context Key: JBTM-3066 URL: https://issues.jboss.org/browse/JBTM-3066 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next If an LRA is associated with a thread and that thread then starts a new LRA then the new one is nested under the first. When using the LRAClient API to start the child LRA the resulting context is left as the parent. This is wrong since the thread should now operate in the context of the nested LRA. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3064) After a crash active LRA's are left in a limbo state

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3064?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3064: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > After a crash active LRA's are left in a limbo state > ---------------------------------------------------- > > Key: JBTM-3064 > URL: https://issues.jboss.org/browse/JBTM-3064 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If an LRA coordinator crashes with active LRA's (ie ones that have not yet been asked to finish) then when the coordinator is restarted they do not appear in the coordinators list so they cannot be ended. > The fix is to ensure that the LRA periodic recovery module adds them back into the coordinators list of active LRA's. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2018