[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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 months
[JBoss JIRA] (WFLY-13803) Upgrade RESTEasy to 3.13.0.Final
by Ronald Sigal (Jira)
Ronald Sigal created WFLY-13803:
-----------------------------------
Summary: Upgrade RESTEasy to 3.13.0.Final
Key: WFLY-13803
URL: https://issues.redhat.com/browse/WFLY-13803
Project: WildFly
Issue Type: Component Upgrade
Components: REST
Reporter: Ronald Sigal
Assignee: Ronald Sigal
Fix For: 20.0.0.Beta1, 20.0.0.Final
Upgrade from 3.11.2.Final to 3.12.0.Final
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFCORE-5104) remoting subsystem's http-connector is missing capability reference
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5104?page=com.atlassian.jira.plug... ]
Brian Stansberry moved WFLY-12356 to WFCORE-5104:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-5104 (was: WFLY-12356)
Component/s: Remoting
(was: Remoting)
Affects Version/s: (was: 17.0.1.Final)
> 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)
5 years, 2 months
[JBoss JIRA] (WFLY-12356) remoting subsystem's http-connector is missing capability reference
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12356?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-12356:
-----------------------------------------
I'm going to move this to WFCORE as that's where the remoting subsystem is.
> remoting subsystem's http-connector is missing capability reference
> -------------------------------------------------------------------
>
> Key: WFLY-12356
> URL: https://issues.redhat.com/browse/WFLY-12356
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 17.0.1.Final
> 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)
5 years, 2 months