[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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 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)
5 years, 2 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 reassigned WFLY-13925:
-------------------------------
Assignee: (was: r searls)
> 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, REST
> 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)
5 years, 2 months