[JBoss JIRA] (WFCORE-5104) remoting subsystem's http-connector is missing capability reference
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5104?page=com.atlassian.jira.plug... ]
Darran Lofthouse commented on WFCORE-5104:
------------------------------------------
We did discuss on the following PR https://github.com/wildfly/wildfly-core/pull/4291 that the remoting layer (not subsystem) needs to move to a feature pack in WildFly, I think that needs to happen before this requirement is added. The remoting layer then needs a dependency on the undertow layer otherwise that capability will not be satisfied so specifying the remoting layer to Galleon could lead to a failed installation / build.
> remoting subsystem's http-connector is missing capability reference
> -------------------------------------------------------------------
>
> Key: WFCORE-5104
> URL: https://issues.redhat.com/browse/WFCORE-5104
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Radoslav Husar
> Assignee: Ranabir Chakraborty
> Priority: Major
> Labels: ux
>
> http-remoting-connector is missing capability reference to the undertow connector.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=connector-ref,value=foo)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> results in a cryptic error
> {noformat}
> 11:33:01,792 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings, service org.wildfly.ejb.remote]
> WFLYCTL0448: 5 additional services are down due to their dependencies being missing or failed
> 11:33:15,334 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0185: Newly corrected services:
> service jboss.ejb.association (new available)
> service jboss.ejb.remoting.connector.client-mappings (new available)
> service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (no longer required)
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (new available)
> service org.wildfly.clustering.cache.registry-factory.ejb.client-mappings (new available)
> service org.wildfly.clustering.group.ejb (new available)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 10 months
[JBoss JIRA] (DROOLS-5539) Review dmn examples version in codebase
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5539?page=com.atlassian.jira.plug... ]
Matteo Mortari resolved DROOLS-5539.
------------------------------------
Resolution: Done
> Review dmn examples version in codebase
> ---------------------------------------
>
> Key: DROOLS-5539
> URL: https://issues.redhat.com/browse/DROOLS-5539
> Project: Drools
> Issue Type: Story
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
> Labels: core-team
>
> *Motivation*: avoid a User might find *_easily_* an outdated version (DMN v1.1) in the examples from our codebase.
> *Goal*: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure.
> *Impacts*: kie-dmn codebase in drools.git and downstream repos to be assessed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 10 months
[JBoss JIRA] (DROOLS-5539) Review dmn examples version in codebase
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5539?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5539:
----------------------------------------
In conclusion, this required quite some solid work over the course of *+5 weeks+*,
but *+18 PRs+* later,
I am nearing completion of what was originally requested by dealing with approximately *+595 DMN files+*,
either migrating them from v1.1 to v1.2, and/or archiving them in a separate, well-isolated module.
This work spanned {{drools}}, {{jbpm}}, {{droolsjbpm-integration}} and {{kogito-runtimes}} repos beyond what mentioned at some point, so a total of 4 repos have been impacted.
I haven't found for instance any DMNv1.2 inside {{kogito-examples}} and other example repos.
I have not touched "front-end repos" since I assume those will be dealt-with as part of the front-end work itself, but I remain available if my support is still needed.
If something still be missing, as part of this DROOLS-5539,
it should contain everything required from tracking the work done to the tool I used to perform the migration [https://github.com/kiegroup/kie-dmn-versionconverter]
which required several iteration to correctly deal with *_some_* edge-cases, which crippled down to *_many_* of the files subject of migration.
> Review dmn examples version in codebase
> ---------------------------------------
>
> Key: DROOLS-5539
> URL: https://issues.redhat.com/browse/DROOLS-5539
> Project: Drools
> Issue Type: Story
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
> Labels: core-team
>
> *Motivation*: avoid a User might find *_easily_* an outdated version (DMN v1.1) in the examples from our codebase.
> *Goal*: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure.
> *Impacts*: kie-dmn codebase in drools.git and downstream repos to be assessed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 10 months
[JBoss JIRA] (WFWIP-334) Bootable JAR - Cloud - Support for dns.DNS_PING
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-334?page=com.atlassian.jira.plugin... ]
Martin Choma edited comment on WFWIP-334 at 8/27/20 2:50 AM:
-------------------------------------------------------------
There is lot of environment properties in s2i which are related to configuring clustering (~10) . [1]
{code}
OPENSHIFT_KUBE_PING_*
OPENSHIFT_DNS_PING_*
JGROUPS_*
{code}
If I understand correctly what you are suggesting here is add support for one of them {{JGROUPS_PING_PROTOCOL}}. But that leaves us with 10 other properties where customer need to leverage custom CLI anyway. My point is if it so helpful for user - I assume it is just changing one value in model?
My feeling from yesterdays meeting was design purpose is to keep <cloud> logic as small as possible.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
was (Author: mchoma):
There is lot of environment properties in s2i which are related to configuring clustering (~10) . [1]
If I understand correctly what you are suggesting here is add support for one of them {{JGROUPS_PING_PROTOCOL}}. But that leaves us with 10 other properties where customer need to leverage custom CLI anyway. My point is if it so helpful for user - I assume it is just changing one value in model?
{code}
OPENSHIFT_KUBE_PING_*
OPENSHIFT_DNS_PING_*
JGROUPS_*
{code}
My feeling from yesterdays meeting was design purpose is to keep <cloud> logic as small as possible.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
> Bootable JAR - Cloud - Support for dns.DNS_PING
> -----------------------------------------------
>
> Key: WFWIP-334
> URL: https://issues.redhat.com/browse/WFWIP-334
> Project: WildFly WIP
> Issue Type: Feature Request
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> Currently kubernetes.KUBE_PING is the protocol in use when cloud is enabled.
> KUBE_PING, although requiring an Openshift permission, is the simpler configuration wise (just need KUBERNETES namespace and your are done).
> DNS_PING doesn't require the extra permission but requires a new service (to expose the port 8888 in the pod) to be created.
> I propose that we keep KUBE_PING as the default protocol and extend the cloud element with a <ping-protocol>kubernetes.KUBE_PING|dns.DNS_PING</ping-protocol> element.
> The env variable used to set the service name is the same as EAP/XP S2I builder image: OPENSHIFT_DNS_PING_SERVICE_NAME
> web-clustering example will be evolved with a profile to support DNS_PING (and also to contain a yaml example file of the ping service).
> [~luck3y], [~mchoma], [~brian.stansberry] [~fburzigo] that is the proposal to also cover DNS_PING.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 10 months
[JBoss JIRA] (ELY-1851) Elytron ldaps realm fails if a referral is returned inside a search
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/ELY-1851?page=com.atlassian.jira.plugin.... ]
Chao Wang updated ELY-1851:
---------------------------
Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1307 (was: https://github.com/wildfly-security/wildfly-elytron/pull/1307, https://github.com/wildfly-security/wildfly-elytron/pull/1435)
> Elytron ldaps realm fails if a referral is returned inside a search
> -------------------------------------------------------------------
>
> Key: ELY-1851
> URL: https://issues.redhat.com/browse/ELY-1851
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.6.3.Final, 1.10.8.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
>
> Elytron LdapRealm fails to follow a referral when ldaps is used (the {{ThreadLocalSSLSocketFactory}} is not set).
> With a configuration similar to this one ({{memberOf}} is used to locate groups):
> {code:xml}
> <ldap-realm name="ldap-realm" dir-context="ldap-dir-context" direct-verification="true">
> <identity-mapping rdn-identifier="sAMAccountName" use-recursive-search="true" search-base-dn="DC=redhat,DC=com">
> <attribute-mapping>
> <attribute reference="memberOf" from="cn" to="Roles" role-recursion="3"/>
> </attribute-mapping>
> </identity-mapping>
> </ldap-realm>
> ...
> <dir-context name="ldap-dir-context" url="ldaps://ldap.redhat.com:636" principal="cn=Administrator,cn=Users,DC=redhat,DC=com" referral-mode="FOLLOW" ssl-context="ldaps-context">
> <credential-reference store="credstore" alias="ldap_password"/>
> </dir-context>
> {code}
> If we have a group (or user) which contains a {{memberOf}} of another ldap, something like the following:
> {noformat}
> dn: CN=group-with-external-members,OU=Groups,DC=redhat,DC=com
> ...
> memberOf: CN=group-in-another-domain,OU=Groups,DC=lab,DC=redhat,DC=com
> {noformat}
> The following exception is thrown when a referral is returned for a group that is inside another ldapserver of the forest:
> {noformat}
> TRACE [org.jboss.remoting.remote.server] (management task-1) Server sending authentication rejected: java.lang.RuntimeException: ELY01079: ldap-realm realm failed to obtain attributes for entry [CN=group-with-external-members,OU=Groups,DC=redhat,DC=com]
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributesFromSearch(LdapSecurityRealm.java:808)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$4(LdapSecurityRealm.java:768)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.forEachAttributeValue(LdapSecurityRealm.java:841)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:766)
> at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1321)
> at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:828)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:754)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAttributes(LdapSecurityRealm.java:516)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAuthorizationIdentity(LdapSecurityRealm.java:497)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1923)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1952)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:509)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:489)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:872)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:60)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:146)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:942)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: ldap-realm realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1141)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributesFromSearch(LdapSecurityRealm.java:797)
> ... 46 more
> Caused by: javax.naming.CommunicationException: ldap.lab.redhat.com:636 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without ThreadLocalSSLSocketFactory thread local setting]
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:96)
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:151)
> at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1861)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:335)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.searchWithPagination(LdapSecurityRealm.java:1161)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1038)
> ... 47 more
> Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without ThreadLocalSSLSocketFactory thread local setting
> at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:296)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:215)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1609)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
> at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
> at org.jboss.as.naming.context.ObjectFactoryBuilder$ReferenceUrlContextFactoryWrapper.getObjectInstance(ObjectFactoryBuilder.java:293)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:119)
> ... 58 more
> {noformat}
> The reason seems to be that the {{ThreadLocalSSLSocketFactory}} is not set when doing a search, so, if a referral is returned the new search created inside the current one has no access to the {{SSLSocketFactory}} in the thread local.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 10 months
[JBoss JIRA] (JBMETA-419) Add parsing of EE 9 spec documents
by Brian Stansberry (Jira)
Brian Stansberry created JBMETA-419:
---------------------------------------
Summary: Add parsing of EE 9 spec documents
Key: JBMETA-419
URL: https://issues.redhat.com/browse/JBMETA-419
Project: JBoss Metadata
Issue Type: Feature Request
Components: client, common, ear, ejb, rar, web
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Add the EE 9 xsds and parsers to parse them.
Generally these are the same as the EE 8 ones.
Note this is not about producing objects that use EE 9 APIs (i.e. jakarta.* packages instead of javax.*.)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 10 months
[JBoss JIRA] (WFWIP-335) Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
by Jan Stourac (Jira)
Jan Stourac created WFWIP-335:
---------------------------------
Summary: Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
Key: WFWIP-335
URL: https://issues.redhat.com/browse/WFWIP-335
Project: WildFly WIP
Issue Type: Bug
Components: Security
Reporter: Jan Stourac
Assignee: Farah Juma
There is failing a new test directly in your PR for 'wildfly-openssl' project - [org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherS...]. I encountered this failure on RHEL8 with OpenSSL 1.1.1c installed:
{code:title=ComparisonFailure}
testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.112 sec <<< FAILURE!
org.junit.ComparisonFailure: expected:<TLS_[AES_256_GCM_SHA384]> but was:<TLS_[CHACHA20_POLY1305_SHA256]>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:170)
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:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
After some investigation, it looks like this failure is tied with this version of OpenSSL and does not occur with newer 1.1.1g version. I also saw another failure with combination of OpenJDK 11.0.4 and OpenSSL 1.1.1c:
{code:title=different failure - API incompatibility?}
testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.031 sec <<< ERROR!
javax.net.ssl.SSLException: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
at org.wildfly.openssl.OpenSSLEngine.handshake(OpenSSLEngine.java:1129)
at org.wildfly.openssl.OpenSSLEngine.beginHandshakeImplicitly(OpenSSLEngine.java:1071)
at org.wildfly.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:435)
at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479)
at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:305)
at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:509)
at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:555)
at org.wildfly.openssl.OpenSSLOutputStream.write(OpenSSLOutputStream.java:51)
at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:159)
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:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
Here is a summary, see:
{quote}
OpenJDK 11.0.4 + OpenSSL 1.1.1c = fail - different failure - some API incompatibilty???
OpenJDK 11.0.4 + OpenSSL 1.1.1g = pass
OpenJDK 11.0.6 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
OpenJDK 11.0.6 + OpenSSL 1.1.1g = pass
OpenJDK 11.0.8 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
OpenJDK 11.0.8 + OpenSSL 1.1.1g = pass
{quote}
Basically means that newer OpenSSL works okay. Although, this may still be problem for customers of RHEL8 until OpenSSL there is not updated.
Not sure whether this test failure may have any real bad effect on customers, still I wanted to point this out here
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 10 months