[JBoss JIRA] (ELY-1629) Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
by Daniel McCarney (JIRA)
[ https://issues.jboss.org/browse/ELY-1629?page=com.atlassian.jira.plugin.s... ]
Daniel McCarney updated ELY-1629:
---------------------------------
Description:
Hi folks,
First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key...] that I think may affect your project based on this code snippet:
https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
Thanks!
was:
Hi folks :wave:,
First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key...] that I think may affect your project based on this code snippet:
https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
Thanks!
> Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
> ------------------------------------------------------------
>
> Key: ELY-1629
> URL: https://issues.jboss.org/browse/ELY-1629
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Daniel McCarney
> Assignee: Darran Lofthouse
>
> Hi folks,
> First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
> I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key...] that I think may affect your project based on this code snippet:
> https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
> While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
> Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1629) Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
by Daniel McCarney (JIRA)
[ https://issues.jboss.org/browse/ELY-1629?page=com.atlassian.jira.plugin.s... ]
Daniel McCarney updated ELY-1629:
---------------------------------
Description:
Hi folks :wave:,
First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key...] that I think may affect your project based on this code snippet:
https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
Thanks!
was:
Hi folks :wave:,
First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change]|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-ke... that I think may affect your project based on this code snippet:
https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
Thanks!
> Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
> ------------------------------------------------------------
>
> Key: ELY-1629
> URL: https://issues.jboss.org/browse/ELY-1629
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Daniel McCarney
> Assignee: Darran Lofthouse
>
> Hi folks :wave:,
> First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
> I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key...] that I think may affect your project based on this code snippet:
> https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
> While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
> Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1629) Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
by Daniel McCarney (JIRA)
Daniel McCarney created ELY-1629:
------------------------------------
Summary: Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
Key: ELY-1629
URL: https://issues.jboss.org/browse/ELY-1629
Project: WildFly Elytron
Issue Type: Feature Request
Reporter: Daniel McCarney
Assignee: Darran Lofthouse
Hi folks :wave:,
First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change](https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-ke... that I think may affect your project based on this code snippet:
https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1629) Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
by Daniel McCarney (JIRA)
[ https://issues.jboss.org/browse/ELY-1629?page=com.atlassian.jira.plugin.s... ]
Daniel McCarney updated ELY-1629:
---------------------------------
Description:
Hi folks :wave:,
First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change]|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-ke... that I think may affect your project based on this code snippet:
https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
Thanks!
was:
Hi folks :wave:,
First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change](https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-ke... that I think may affect your project based on this code snippet:
https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
Thanks!
> Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
> ------------------------------------------------------------
>
> Key: ELY-1629
> URL: https://issues.jboss.org/browse/ELY-1629
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Daniel McCarney
> Assignee: Darran Lofthouse
>
> Hi folks :wave:,
> First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
> I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change]|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-ke... that I think may affect your project based on this code snippet:
> https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
> While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
> Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10821) ASM 6.2.1 is not JDK11 ready
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10821?page=com.atlassian.jira.plugin... ]
Richard Opalka updated WFLY-10821:
----------------------------------
Labels: jdk11 (was: )
> ASM 6.2.1 is not JDK11 ready
> ----------------------------
>
> Key: WFLY-10821
> URL: https://issues.jboss.org/browse/WFLY-10821
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Richard Opalka
> Assignee: Scott Marlow
> Priority: Blocker
> Labels: jdk11
> Fix For: 14.0.0.CR1
>
>
> The following two tests are failing on JDK11:
> * testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyAndJDSEnabledTransformerTestCase.java
> * testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyEnabledTransformerTestCase.java
> The reason is the following stack trace:
> java.lang.UnsupportedOperationException
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> <------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
> <------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.access$200(Hibernate51CompatibilityTransformer.java:50)
> <------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer$2.visit(Hibernate51CompatibilityTransformer.java:378)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:525)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> <------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
> <------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.transform(Hibernate51CompatibilityTransformer.java:76)
> <------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform(DelegatingClassFileTransformer.java:60)
> <------>at org.jboss.modules.JLIClassTransformer.transform(JLIClassTransformer.java:55)
> <------>at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:503)
> <------>at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> <------>at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> <------>at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> <------>at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> <------>at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> <------>at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> <------>at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> <------>at deployment.arquillian-service//org.jboss.as.arquillian.service.ArquillianServiceActivator.activate(ArquillianServiceActivator.java:35)
> <------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91)
> <------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
> <------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> <------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> <------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> <------>at java.base/java.lang.Thread.run(Thread.java:834)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10821) ASM 6.2.1 is not JDK11 ready
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10821?page=com.atlassian.jira.plugin... ]
Richard Opalka updated WFLY-10821:
----------------------------------
Description:
The following two tests are failing on JDK11:
* testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyAndJDSEnabledTransformerTestCase.java
* testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyEnabledTransformerTestCase.java
The reason is the following stack trace:
java.lang.UnsupportedOperationException
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
<------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.access$200(Hibernate51CompatibilityTransformer.java:50)
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer$2.visit(Hibernate51CompatibilityTransformer.java:378)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:525)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
<------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.transform(Hibernate51CompatibilityTransformer.java:76)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform(DelegatingClassFileTransformer.java:60)
<------>at org.jboss.modules.JLIClassTransformer.transform(JLIClassTransformer.java:55)
<------>at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:503)
<------>at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
<------>at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
<------>at org.jboss.modules.Module.loadModuleClass(Module.java:731)
<------>at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
<------>at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
<------>at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
<------>at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
<------>at deployment.arquillian-service//org.jboss.as.arquillian.service.ArquillianServiceActivator.activate(ArquillianServiceActivator.java:35)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
<------>at java.base/java.lang.Thread.run(Thread.java:834)
These tests are passing on JDK8, JDK9 & JDK10.
was:
The following two tests are failing on JDK11:
* testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyAndJDSEnabledTransformerTestCase.java
* testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyEnabledTransformerTestCase.java
The reason is the following stack trace:
java.lang.UnsupportedOperationException
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
<------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.access$200(Hibernate51CompatibilityTransformer.java:50)
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer$2.visit(Hibernate51CompatibilityTransformer.java:378)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:525)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
<------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.transform(Hibernate51CompatibilityTransformer.java:76)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform(DelegatingClassFileTransformer.java:60)
<------>at org.jboss.modules.JLIClassTransformer.transform(JLIClassTransformer.java:55)
<------>at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:503)
<------>at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
<------>at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
<------>at org.jboss.modules.Module.loadModuleClass(Module.java:731)
<------>at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
<------>at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
<------>at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
<------>at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
<------>at deployment.arquillian-service//org.jboss.as.arquillian.service.ArquillianServiceActivator.activate(ArquillianServiceActivator.java:35)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
<------>at java.base/java.lang.Thread.run(Thread.java:834)
> ASM 6.2.1 is not JDK11 ready
> ----------------------------
>
> Key: WFLY-10821
> URL: https://issues.jboss.org/browse/WFLY-10821
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Richard Opalka
> Assignee: Scott Marlow
> Priority: Blocker
> Labels: jdk11
> Fix For: 14.0.0.CR1
>
>
> The following two tests are failing on JDK11:
> * testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyAndJDSEnabledTransformerTestCase.java
> * testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyEnabledTransformerTestCase.java
> The reason is the following stack trace:
> java.lang.UnsupportedOperationException
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> <------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
> <------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.access$200(Hibernate51CompatibilityTransformer.java:50)
> <------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer$2.visit(Hibernate51CompatibilityTransformer.java:378)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:525)
> <------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> <------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
> <------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.transform(Hibernate51CompatibilityTransformer.java:76)
> <------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform(DelegatingClassFileTransformer.java:60)
> <------>at org.jboss.modules.JLIClassTransformer.transform(JLIClassTransformer.java:55)
> <------>at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:503)
> <------>at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> <------>at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> <------>at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> <------>at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> <------>at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> <------>at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> <------>at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> <------>at deployment.arquillian-service//org.jboss.as.arquillian.service.ArquillianServiceActivator.activate(ArquillianServiceActivator.java:35)
> <------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91)
> <------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
> <------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> <------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> <------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> <------>at java.base/java.lang.Thread.run(Thread.java:834)
> These tests are passing on JDK8, JDK9 & JDK10.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10821) ASM 6.2.1 is not JDK11 ready
by Richard Opalka (JIRA)
Richard Opalka created WFLY-10821:
-------------------------------------
Summary: ASM 6.2.1 is not JDK11 ready
Key: WFLY-10821
URL: https://issues.jboss.org/browse/WFLY-10821
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Reporter: Richard Opalka
Assignee: Scott Marlow
Priority: Blocker
Fix For: 14.0.0.CR1
The following two tests are failing on JDK11:
* testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyAndJDSEnabledTransformerTestCase.java
* testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/transformer/VerifyHibernate51CompatibilityPropertyEnabledTransformerTestCase.java
The reason is the following stack trace:
java.lang.UnsupportedOperationException
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
<------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.access$200(Hibernate51CompatibilityTransformer.java:50)
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer$2.visit(Hibernate51CompatibilityTransformer.java:378)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:525)
<------>at asm.asm@6.2.1//org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
<------>at org.hibernate.bytecodetransformer(a)14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.collectClassesAndInterfaces(Hibernate51CompatibilityTransformer.java:
<------>at org.hibernate.bytecodetransformer@14.0.0.Beta2-SNAPSHOT//org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.transform(Hibernate51CompatibilityTransformer.java:76)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform(DelegatingClassFileTransformer.java:60)
<------>at org.jboss.modules.JLIClassTransformer.transform(JLIClassTransformer.java:55)
<------>at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:503)
<------>at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
<------>at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
<------>at org.jboss.modules.Module.loadModuleClass(Module.java:731)
<------>at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
<------>at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
<------>at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
<------>at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
<------>at deployment.arquillian-service//org.jboss.as.arquillian.service.ArquillianServiceActivator.activate(ArquillianServiceActivator.java:35)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91)
<------>at org.jboss.as.server@6.0.0.Alpha6-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
<------>at org.jboss.msc@1.4.2.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
<------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
<------>at java.base/java.lang.Thread.run(Thread.java:834)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2787:
-------------------------------------
Reference link for brainstorming around the enumeration widget.
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Manage1.png, Manage2.png, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, Screen Shot 2018-07-27 at 12.24.49 PM.png, Screen Shot 2018-07-27 at 12.27.13 PM.png, Screen Shot 2018-08-09 at 2.09.21 PM.png, add_basic.png, treegrid.png, type_definitions.pdf
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (LOGMGR-200) SSLProtocolException: Connection reset on JDK11
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-200?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-200:
--------------------------------------
AIUI you can only shutdown the input and output. Attempting to shutdown the output before the close didn't seem to fix the issue. When I debug I get a completely different error which may be a clue:
{code}
LogManager error of type FLUSH_FAILURE: Error on flush
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:312)
at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:270)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877)
at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383)
at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:477)
at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:709)
at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:188)
at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233)
at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312)
at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316)
at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153)
at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:254)
at org.jboss.logmanager.handlers.SocketHandler.safeFlush(SocketHandler.java:512)
at org.jboss.logmanager.handlers.SocketHandler.flush(SocketHandler.java:228)
at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
at org.jboss.logmanager.handlers.SocketHandler.doPublish(SocketHandler.java:218)
at org.jboss.logmanager.handlers.SocketHandlerTests.testTlsConnection(SocketHandlerTests.java:59)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
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:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
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:379)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
{code}
[~honza889] Do you by chance know if there were changes to how SSL should be configured in Java 11? I'll dig around and see what I can find as well.
> SSLProtocolException: Connection reset on JDK11
> -----------------------------------------------
>
> Key: LOGMGR-200
> URL: https://issues.jboss.org/browse/LOGMGR-200
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.4.Final
> Reporter: Jan Kalina
> Priority: Blocker
>
> testTlsConnection and other SSL related tests in SocketHandlerTests fails on JDK11:
> {code}
> LogManager error of type FLUSH_FAILURE: Error on flush
> javax.net.ssl.SSLProtocolException: Connection reset
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126)
> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:325)
> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:268)
> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877)
> at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810)
> at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383)
> at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:477)
> at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:709)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:188)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233)
> at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312)
> at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316)
> at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153)
> at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:254)
> at org.jboss.logmanager.handlers.SocketHandler.safeFlush(SocketHandler.java:512)
> at org.jboss.logmanager.handlers.SocketHandler.flush(SocketHandler.java:228)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
> at org.jboss.logmanager.handlers.SocketHandler.doPublish(SocketHandler.java:218)
> at org.jboss.logmanager.handlers.SocketHandlerTests.testTlsConnection(SocketHandlerTests.java:59)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 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:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> 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 com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131)
> Caused by: java.net.SocketException: Connection reset
> at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
> at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464)
> at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
> ... 46 more
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.logmanager.handlers.SocketHandlerTests.testTlsConnection(SocketHandlerTests.java:61)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 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:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> 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 com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months