[JBoss JIRA] (WFLY-13928) EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13928?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13928:
------------------------------------
Description:
This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; but it works in this case because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
was:
This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; it works because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
> EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13928
> URL: https://issues.redhat.com/browse/WFLY-13928
> Project: WildFly
> Issue Type: Task
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Major
>
> This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
> EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; but it works in this case because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
> Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
> Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFLY-13928) EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13928:
---------------------------------------
Summary: EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
Key: WFLY-13928
URL: https://issues.redhat.com/browse/WFLY-13928
Project: WildFly
Issue Type: Task
Components: Web Services
Reporter: Brian Stansberry
Assignee: Jim Ma
This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; it works because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ]
Sonia Zaldana reassigned WFCORE-5133:
-------------------------------------
Assignee: (was: Darran Lofthouse)
> SNICombinedWithALPNTestCase fails with oracle JDK 8 261
> -------------------------------------------------------
>
> Key: WFCORE-5133
> URL: https://issues.redhat.com/browse/WFCORE-5133
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Priority: Major
>
> Exception while using oracle JDK 261:
>
> {code}
> at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444)
> at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439)
> at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430)
> at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ]
Sonia Zaldana commented on WFCORE-5133:
---------------------------------------
I am removing myself from this issue, as it seems like it is a larger issue than originally expected and we are waiting for input from Flavia. I would be happy to reassign myself if my help is needed.
> SNICombinedWithALPNTestCase fails with oracle JDK 8 261
> -------------------------------------------------------
>
> Key: WFCORE-5133
> URL: https://issues.redhat.com/browse/WFCORE-5133
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Major
>
> Exception while using oracle JDK 261:
>
> {code}
> at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444)
> at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439)
> at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430)
> at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ]
Sonia Zaldana reassigned WFCORE-5133:
-------------------------------------
Assignee: Darran Lofthouse (was: Sonia Zaldana)
> SNICombinedWithALPNTestCase fails with oracle JDK 8 261
> -------------------------------------------------------
>
> Key: WFCORE-5133
> URL: https://issues.redhat.com/browse/WFCORE-5133
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Major
>
> Exception while using oracle JDK 261:
>
> {code}
> at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444)
> at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439)
> at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430)
> at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFLY-13925) Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13925?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13925:
-----------------------------------------
Shouldn't that dependency be 'provided' scope? JaxrsDependencyProcessor will add that dep to the deployment classpath if the module is present.
> Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13925
> URL: https://issues.redhat.com/browse/WFLY-13925
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client, Web (Undertow)
> Affects Versions: 21.0.0.Beta1
> Reporter: Martin Stefanko
> Priority: Major
>
> This project defines a simple REST endpoint. When the archive is built and deployed without archive org.jboss.resteasy:resteasy-client-microprofile (see pom.xml lines 18-22) the endpoint can be reached successfully. When the archive is built and deployed with org.jboss.resteasy:resteasy-client-microprofile the endpoint can not be reached.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFLY-13925) Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
by r searls (Jira)
[ https://issues.redhat.com/browse/WFLY-13925?page=com.atlassian.jira.plugi... ]
r searls updated WFLY-13925:
----------------------------
Description:
This project defines a simple REST endpoint. When the archive is built and deployed without archive org.jboss.resteasy:resteasy-client-microprofile (see pom.xml lines 18-22) the endpoint can be reached successfully. When the archive is built and deployed with org.jboss.resteasy:resteasy-client-microprofile the endpoint can not be reached.
was:
This project defines a simple REST endpoint. When the archive is built and deployed without archive org.jboss.resteasy:resteasy-client-microprofile (see pom.xml lines 18-22) the endpoint can be reached successfully. When the archive is built and deployed with org.jboss.resteasy:resteasy-client-microprofile the endpoint can not be reached.
Quoting [~rsearls]:
This appears to be an issue in wfly deployment processing.
I can confirm when deploying the app that contains resteasy-client-microprofile
the servlet executed by undertow is io.undertow.servlet.handlers.DefaultServlet.
When the app does not contain resteasy-client-microprofile the servlet executed
by undertow is org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher.
Setting a breakpoint in io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy
line 300, method start() you will see ServletInfo\{mappings=[], servletClass=class io.undertow.servlet.handlers.DefaultServlet, name='default'}
when the app contains resteasy-client-microprofile and value
ServletInfo{mappings=[/*], servletClass=class org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher, name='io.xstefank.RestApplication'}
when it does not.
In wfly I looked at the jaxrs deployment code. I can see that for both
apps, servletClass is assigned org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
but when resteasy-client-microprofile is present some wfly process that runs after
jaxrs overwrites this information with servletClass=class io.undertow.servlet.handlers.DefaultServlet.
> Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13925
> URL: https://issues.redhat.com/browse/WFLY-13925
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client, Web (Undertow)
> Affects Versions: 21.0.0.Beta1
> Reporter: Martin Stefanko
> Priority: Major
>
> This project defines a simple REST endpoint. When the archive is built and deployed without archive org.jboss.resteasy:resteasy-client-microprofile (see pom.xml lines 18-22) the endpoint can be reached successfully. When the archive is built and deployed with org.jboss.resteasy:resteasy-client-microprofile the endpoint can not be reached.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFLY-13925) Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
by r searls (Jira)
[ https://issues.redhat.com/browse/WFLY-13925?page=com.atlassian.jira.plugi... ]
r searls updated WFLY-13925:
----------------------------
Description:
This project defines a simple REST endpoint. When the archive is built and deployed without archive org.jboss.resteasy:resteasy-client-microprofile (see pom.xml lines 18-22) the endpoint can be reached successfully. When the archive is built and deployed with org.jboss.resteasy:resteasy-client-microprofile the endpoint can not be reached.
Quoting [~rsearls]:
This appears to be an issue in wfly deployment processing.
I can confirm when deploying the app that contains resteasy-client-microprofile
the servlet executed by undertow is io.undertow.servlet.handlers.DefaultServlet.
When the app does not contain resteasy-client-microprofile the servlet executed
by undertow is org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher.
Setting a breakpoint in io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy
line 300, method start() you will see ServletInfo\{mappings=[], servletClass=class io.undertow.servlet.handlers.DefaultServlet, name='default'}
when the app contains resteasy-client-microprofile and value
ServletInfo{mappings=[/*], servletClass=class org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher, name='io.xstefank.RestApplication'}
when it does not.
In wfly I looked at the jaxrs deployment code. I can see that for both
apps, servletClass is assigned org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
but when resteasy-client-microprofile is present some wfly process that runs after
jaxrs overwrites this information with servletClass=class io.undertow.servlet.handlers.DefaultServlet.
was:
Quoting [~rsearls]:
This appears to be an issue in wfly deployment processing.
I can confirm when deploying the app that contains resteasy-client-microprofile
the servlet executed by undertow is io.undertow.servlet.handlers.DefaultServlet.
When the app does not contain resteasy-client-microprofile the servlet executed
by undertow is org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher.
Setting a breakpoint in io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy
line 300, method start() you will see ServletInfo\{mappings=[], servletClass=class io.undertow.servlet.handlers.DefaultServlet, name='default'}
when the app contains resteasy-client-microprofile and value
ServletInfo\{mappings=[/*], servletClass=class org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher, name='io.xstefank.RestApplication'}
when it does not.
In wfly I looked at the jaxrs deployment code. I can see that for both
apps, servletClass is assigned org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
but when resteasy-client-microprofile is present some wfly process that runs after
jaxrs overwrites this information with servletClass=class io.undertow.servlet.handlers.DefaultServlet.
Steps to Reproduce:
The test case is here
https://github.com/rsearls/WFLY-13925-testcase.git
Case 1, the successful case.
build this project
deploy the app to wildfly-21.0.0.Beta1-SNAPSHOT
Use cURL to call the endpoint
curl -v http://localhost:8080/rest-client-wfly/ping
Case 2, the unsuccessful case.
Edit pom.xml and uncomment archive org.jboss.resteasy:resteasy-client-microprofile
build this project
deploy the app to wildfly-21.0.0.Beta1-SNAPSHOT
Use cURL to call the endpoint
curl -v http://localhost:8080/rest-client-wfly/ping
Quoting [~rsearls]:
This appears to be an issue in wfly deployment processing.
I can confirm when deploying the app that contains resteasy-client-microprofile
the servlet executed by undertow is io.undertow.servlet.handlers.DefaultServlet.
When the app does not contain resteasy-client-microprofile the servlet executed
by undertow is org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher.
Setting a breakpoint in io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy
line 300, method start() you will see ServletInfo\{mappings=[], servletClass=class io.undertow.servlet.handlers.DefaultServlet, name='default'}
when the app contains resteasy-client-microprofile and value
ServletInfo{mappings=[/*], servletClass=class org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher, name='io.xstefank.RestApplication'}
when it does not.
In wfly I looked at the jaxrs deployment code. I can see that for both
apps, servletClass is assigned org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
but when resteasy-client-microprofile is present some wfly process that runs after
jaxrs overwrites this information with servletClass=class io.undertow.servlet.handlers.DefaultServlet.
> Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13925
> URL: https://issues.redhat.com/browse/WFLY-13925
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client, Web (Undertow)
> Affects Versions: 21.0.0.Beta1
> Reporter: Martin Stefanko
> Priority: Major
>
> This project defines a simple REST endpoint. When the archive is built and deployed without archive org.jboss.resteasy:resteasy-client-microprofile (see pom.xml lines 18-22) the endpoint can be reached successfully. When the archive is built and deployed with org.jboss.resteasy:resteasy-client-microprofile the endpoint can not be reached.
>
>
>
>
> Quoting [~rsearls]:
>
> This appears to be an issue in wfly deployment processing.
> I can confirm when deploying the app that contains resteasy-client-microprofile
> the servlet executed by undertow is io.undertow.servlet.handlers.DefaultServlet.
> When the app does not contain resteasy-client-microprofile the servlet executed
> by undertow is org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher.
> Setting a breakpoint in io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy
> line 300, method start() you will see ServletInfo\{mappings=[], servletClass=class io.undertow.servlet.handlers.DefaultServlet, name='default'}
> when the app contains resteasy-client-microprofile and value
> ServletInfo{mappings=[/*], servletClass=class org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher, name='io.xstefank.RestApplication'}
> when it does not.
> In wfly I looked at the jaxrs deployment code. I can see that for both
> apps, servletClass is assigned org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
> but when resteasy-client-microprofile is present some wfly process that runs after
> jaxrs overwrites this information with servletClass=class io.undertow.servlet.handlers.DefaultServlet.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFLY-13925) Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
by r searls (Jira)
[ https://issues.redhat.com/browse/WFLY-13925?page=com.atlassian.jira.plugi... ]
r searls updated WFLY-13925:
----------------------------
Component/s: Web (Undertow)
(was: REST)
> Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13925
> URL: https://issues.redhat.com/browse/WFLY-13925
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client, Web (Undertow)
> Affects Versions: 21.0.0.Beta1
> Reporter: Martin Stefanko
> Priority: Major
>
> Quoting [~rsearls]:
>
> This appears to be an issue in wfly deployment processing.
> I can confirm when deploying the app that contains resteasy-client-microprofile
> the servlet executed by undertow is io.undertow.servlet.handlers.DefaultServlet.
> When the app does not contain resteasy-client-microprofile the servlet executed
> by undertow is org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher.
> Setting a breakpoint in io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy
> line 300, method start() you will see ServletInfo\{mappings=[], servletClass=class io.undertow.servlet.handlers.DefaultServlet, name='default'}
> when the app contains resteasy-client-microprofile and value
> ServletInfo\{mappings=[/*], servletClass=class org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher, name='io.xstefank.RestApplication'}
> when it does not.
> In wfly I looked at the jaxrs deployment code. I can see that for both
> apps, servletClass is assigned org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
> but when resteasy-client-microprofile is present some wfly process that runs after
> jaxrs overwrites this information with servletClass=class io.undertow.servlet.handlers.DefaultServlet.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months