June 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3336) CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11.

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3336?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3336: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11. > --------------------------------------------------------------------------------------------- > > Key: JBTM-3336 > URL: https://issues.redhat.com/browse/JBTM-3336 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Miloslav Žežulka > Assignee: Miloslav Žežulka > Priority: Minor > Fix For: 5.next > > > When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following stacktrace: > {code} > Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at org.jacorb.orb.ORB.getReference(Unknown Source) > at org.jacorb.poa.POA.getReference(Unknown Source) > at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) > at org.jacorb.naming.NameServer.main(Unknown Source) > Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 13 more > {code} > The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3318) TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3318?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3318: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI > ------------------------------------------------------------------- > > Key: JBTM-3318 > URL: https://issues.redhat.com/browse/JBTM-3318 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: org.eclipse.microprofile.lra.tck.TckRecoveryTests-output.txt > > > The test {{TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} fails on AMS CI. > The CI is a bit slower and it seems the issue consists of timeout handling. > {code} > [INFO] Running org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 57.021 s <<< FAILURE! - in org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] testCancelWhenParticipantIsUnavailable(org.eclipse.microprofile.lra.tck.TckRecoveryTests) Time elapsed: 28.349 s <<< FAILURE! > java.lang.AssertionError: Compensate on restarted service should have been called. Was -1 expected:<200> but was:<500> > at org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable(TckRecoveryTests.java:215) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3325) Create a way to close XAResource at the end of the recovery cycle processing

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/JBTM-3325?page=com.atlassian.jira.plugin... ] Luis Barreiro commented on JBTM-3325: ------------------------------------- Thanks [~ochaloup] for bringing up this topic. Agroal takes a different approach than IronJacamar on recovery. It was debated internally, and the conclusion was that it's better to open a new connection every time than to have to manage the connection. To prevent leaks in this scenario, there must be a way to notify that recovery scan has ended. Ideally, this would be done in either 1) the {{XAResource}} itself, or 2) {{XAResourceRecovery}} as a counterpart of {{getXAResources()}}. The former is impossible to change, for obvious reasons, and I don't see any will to make changes to the latter. I asked for feedback on how to manage the connection liyfecycle and [~mmusgrov] suggested to close the connection on {{TMENDRSCAN}}. Agroal now checks for it and it fixed the connection leaks that were being reported. I then suggest to go beyond that and have the {{XAResource}} implementation to express it's intention to be notified that it's no longer needed by implementing a marker interface, in this case I suggested {{AutoClosable}}. I believe this would be the cleanest way to deal with this problem, given the circumstances. This would be an alternative to 1) above. If [~jhalliday] it's right then it's really concerning, because not only it means that the current implementation is wrong and there is no reliable way to get notified of the end of the recovery, but it also implies that Narayana does not have control on the recovery procedure which baffles me. Go back to keep a connection open for recovery is always an option, but it comes with it's own drawbacks and implementation challenges. I much rather see the effort put into having a reliable way to notify the end of recovery. > Create a way to close XAResource at the end of the recovery cycle processing > ---------------------------------------------------------------------------- > > Key: JBTM-3325 > URL: https://issues.redhat.com/browse/JBTM-3325 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > From discussions about Narayana integration to Agroal (https://agroal.github.io/) there came an idea how to make easier for Agroal to integrate with Narayana recovery processing. > Usually (or at least Agroal does so) the brand new {{XAResource}} is provided from the call of the {{XAResourceRecovery}} (https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/mai...). > aka. Agroal implements the {{XAResourceRecovery}} and register it with the Narayana with adding it to with https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/mai... to be used in {{XARecoveryModule}}. > When the periodic recovery cycle ends the {{XAResource}} is not used (next time the recovery processing calls the {{XAResourceRecovery#getXAResources()}} to get the resource for scanning again). The transaction manager announces that the scan ended with call {{XAResource.recover(XAResource.TMENDRSCAN)}} (this is an internal to how Narayana works). > It would be beneficial provide an option that Narayana closes {{XAResource}}s at the end of the recovery cycle when Narayana does not plan to use it again. > The idea is to check if the {{XAResource}} is {{AutoCloseable}} and if so then the {{XAResource}} is closed at the end of the recovery cycle processing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3336) CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11.

by Anonymous (Jira)

[ https://issues.redhat.com/browse/JBTM-3336?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Miloslav Žežulka created pull request #288 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11. > --------------------------------------------------------------------------------------------- > > Key: JBTM-3336 > URL: https://issues.redhat.com/browse/JBTM-3336 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Miloslav Žežulka > Assignee: Miloslav Žežulka > Priority: Minor > > When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following stacktrace: > {code} > Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at org.jacorb.orb.ORB.getReference(Unknown Source) > at org.jacorb.poa.POA.getReference(Unknown Source) > at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) > at org.jacorb.naming.NameServer.main(Unknown Source) > Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 13 more > {code} > The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3336) CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11.

by Miloslav Žežulka (Jira)

[ https://issues.redhat.com/browse/JBTM-3336?page=com.atlassian.jira.plugin... ] Miloslav Žežulka updated JBTM-3336: ----------------------------------- Description: When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following stacktrace: {code} Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.jacorb.orb.ORB.getReference(Unknown Source) at org.jacorb.poa.POA.getReference(Unknown Source) at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) at org.jacorb.naming.NameServer.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 13 more {code} The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. was: When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following error: {code} Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.jacorb.orb.ORB.getReference(Unknown Source) at org.jacorb.poa.POA.getReference(Unknown Source) at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) at org.jacorb.naming.NameServer.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 13 more {code} The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. > CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11. > --------------------------------------------------------------------------------------------- > > Key: JBTM-3336 > URL: https://issues.redhat.com/browse/JBTM-3336 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Miloslav Žežulka > Assignee: Miloslav Žežulka > Priority: Minor > > When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following stacktrace: > {code} > Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at org.jacorb.orb.ORB.getReference(Unknown Source) > at org.jacorb.poa.POA.getReference(Unknown Source) > at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) > at org.jacorb.naming.NameServer.main(Unknown Source) > Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 13 more > {code} > The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3336) CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11.

by Miloslav Žežulka (Jira)

[ https://issues.redhat.com/browse/JBTM-3336?page=com.atlassian.jira.plugin... ] Miloslav Žežulka updated JBTM-3336: ----------------------------------- Summary: CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11. (was: CORBA classes are missing in the ArjunaJTS/standalone quickstart when run with JDK>=11.) > CORBA classes are missing in the ArjunaJTS/standalone quickstart when executed using JDK>=11. > --------------------------------------------------------------------------------------------- > > Key: JBTM-3336 > URL: https://issues.redhat.com/browse/JBTM-3336 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Miloslav Žežulka > Assignee: Miloslav Žežulka > Priority: Minor > > When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following error: > {code} > Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at org.jacorb.orb.ORB.getReference(Unknown Source) > at org.jacorb.poa.POA.getReference(Unknown Source) > at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) > at org.jacorb.naming.NameServer.main(Unknown Source) > Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 13 more > {code} > The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3336) CORBA classes are missing in the ArjunaJTS/standalone quickstart when run with JDK>=11.

by Miloslav Žežulka (Jira)

[ https://issues.redhat.com/browse/JBTM-3336?page=com.atlassian.jira.plugin... ] Miloslav Žežulka updated JBTM-3336: ----------------------------------- Description: When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following error: {code} Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.jacorb.orb.ORB.getReference(Unknown Source) at org.jacorb.poa.POA.getReference(Unknown Source) at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) at org.jacorb.naming.NameServer.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 13 more {code} The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. was: When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we try to launch the nameserver in the _jacorb_ mode, we get the following error: {code} Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.jacorb.orb.ORB.getReference(Unknown Source) at org.jacorb.poa.POA.getReference(Unknown Source) at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) at org.jacorb.naming.NameServer.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 13 more {code} The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. > CORBA classes are missing in the ArjunaJTS/standalone quickstart when run with JDK>=11. > --------------------------------------------------------------------------------------- > > Key: JBTM-3336 > URL: https://issues.redhat.com/browse/JBTM-3336 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Miloslav Žežulka > Assignee: Miloslav Žežulka > Priority: Minor > > When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we [try to launch the CORBA name server in the _jacorb_ mode|https://github.com/zezulka/quickstart/tree/master/ArjunaJTS/standalo...], we get the following error: > {code} > Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at org.jacorb.orb.ORB.getReference(Unknown Source) > at org.jacorb.poa.POA.getReference(Unknown Source) > at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) > at org.jacorb.naming.NameServer.main(Unknown Source) > Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 13 more > {code} > The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3336) CORBA classes are missing in the ArjunaJTS/standalone quickstart when run with JDK>=11.

by Miloslav Žežulka (Jira)

[ https://issues.redhat.com/browse/JBTM-3336?page=com.atlassian.jira.plugin... ] Miloslav Žežulka updated JBTM-3336: ----------------------------------- Description: When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we try to launch the nameserver in the _jacorb_ mode, we get the following error: {code} Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.jacorb.orb.ORB.getReference(Unknown Source) at org.jacorb.poa.POA.getReference(Unknown Source) at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) at org.jacorb.naming.NameServer.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 13 more {code} The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. was: When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we try to launch the nameserver in the _jacorb_ mode, we get the following error: {code} Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.jacorb.orb.ORB.getReference(Unknown Source) at org.jacorb.poa.POA.getReference(Unknown Source) at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) at org.jacorb.naming.NameServer.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 13 more {code} The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320][https://openjdk.java.net/jeps/320] for more information. > CORBA classes are missing in the ArjunaJTS/standalone quickstart when run with JDK>=11. > --------------------------------------------------------------------------------------- > > Key: JBTM-3336 > URL: https://issues.redhat.com/browse/JBTM-3336 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Miloslav Žežulka > Assignee: Miloslav Žežulka > Priority: Minor > > When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we try to launch the nameserver in the _jacorb_ mode, we get the following error: > {code} > Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at org.jacorb.orb.ORB.getReference(Unknown Source) > at org.jacorb.poa.POA.getReference(Unknown Source) > at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) > at org.jacorb.naming.NameServer.main(Unknown Source) > Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 13 more > {code} > The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320|https://openjdk.java.net/jeps/320] for more information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3336) CORBA classes are missing in the ArjunaJTS/standalone quickstart when run with JDK>=11.

by Miloslav Žežulka (Jira)

Miloslav Žežulka created JBTM-3336: -------------------------------------- Summary: CORBA classes are missing in the ArjunaJTS/standalone quickstart when run with JDK>=11. Key: JBTM-3336 URL: https://issues.redhat.com/browse/JBTM-3336 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Miloslav Žežulka Assignee: Miloslav Žežulka When we try to run the _ArjuntaJTS/standalone_ quickstart, more specifically, when we try to launch the nameserver in the _jacorb_ mode, we get the following error: {code} Exception in thread "main" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.jacorb.orb.ORB.getReference(Unknown Source) at org.jacorb.poa.POA.getReference(Unknown Source) at org.jacorb.poa.POA.create_reference_with_id(Unknown Source) at org.jacorb.naming.NameServer.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 13 more {code} The reason why this happens is that the CORBA module was removed from JDK, starting from 11 (with deprecation in 9). See [JEP 320][https://openjdk.java.net/jeps/320] for more information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3255) Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use`

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3255?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3255. ---------------------------------- Release Notes Text: I haven't seen this issue for a long time and I assume that it was fixed by the provided fix in WFLY testsuite (WFLY-13123). Resolution: Out of Date > Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use` > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-3255 > URL: https://issues.redhat.com/browse/JBTM-3255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Attachments: JBTM-3255-occupied-port-10990.zip > > > There could be observed intermittent failures of AS_TESTS in Narayana CI where the job fails with error {{The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090.}}[1] > The reason seems to be there is probably unfinished application server running from the prior testsuite module. > Here we talk about the second server which starts the port `10090` as the management port. > The arquillian starts the `multinode` module and the first test fails with error that the WildFly can't be started as port can't be bound. > It could be that there is either some process occupying the port `10090` on the Linux machine. > But the more probable is that the prior test which is in `clustering` as `org.jboss.as.test.clustering.cluster.ejb2.stateful.failover.RemoteEJBClientStatefulBeanFailoverTestCase` was not finished properly. > The log files does not show any particular trouble though. > [1] > {code} > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.818 s <<< FAILURE! - in org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase > [ERROR] org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase Time elapsed: 3.818 s <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: > The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090. > Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server. > Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port. > To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.failDueToRunning(ManagedDeployableContainer.java:323) > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:81) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:123) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71) > at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23) > at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 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 2020