[JBoss JIRA] (WFCORE-1987) Unable to define specific worker when using http-upgrade
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFCORE-1987:
----------------------------------------
Summary: Unable to define specific worker when using http-upgrade
Key: WFCORE-1987
URL: https://issues.jboss.org/browse/WFCORE-1987
Project: WildFly Core
Issue Type: Bug
Components: Remoting
Reporter: Radim Hatlapatka
Assignee: David Lloyd
In EAP 7.0.0, there was possible to define different worker for Undertow listener and Remoting.
Now it is not possible and results in \[1\].
The need for having the same XNIO worker used for both Remoting endpoint and Undertow listener used for the http-upgrade should be exposed when doing the configuration changes, either it should be allowed or proper warning shown (at least having it documented in both descriptions and in documentation, including the migration guide), for user to know that such configuration can result in not working remoting calls.
Note, this change in behaviour was introduced when upgrading to XNIO 3.4.0.Final. This might seem as backward compatibility issue from customer as his original configuration working with EAP 7.0.0 will stop working.
\[1\]
{noformat}
08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at Automaticio.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkC08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelAutomaticAutomaticListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)Automatic
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.excAutomatichangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListeAutomaticner(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
hannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7591) Search time limit for ldap search is not configurable in Elytron ldap-realm
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7591:
----------------------------------
Summary: Search time limit for ldap search is not configurable in Elytron ldap-realm
Key: WFLY-7591
URL: https://issues.jboss.org/browse/WFLY-7591
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
Scenario:
I try to configure Elytron ldap-realm with some timeout limit for LDAP search.
It seems there is no option to set search time limit for Elytron ldap-realm. Implementation in Elytron seems that feature is developed, but it is not configurable from server configuration. Legacy security solution allows to configure search time limit for searching LDAP through searchTimeLimit option from LdapExtLoginModule.
Since this feature was provided by legacy solution it should be also available in Elytron.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7591) Search time limit for ldap search is not configurable in Elytron ldap-realm
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7591?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7591:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Search time limit for ldap search is not configurable in Elytron ldap-realm
> ---------------------------------------------------------------------------
>
> Key: WFLY-7591
> URL: https://issues.jboss.org/browse/WFLY-7591
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Scenario:
> I try to configure Elytron ldap-realm with some timeout limit for LDAP search.
> It seems there is no option to set search time limit for Elytron ldap-realm. Implementation in Elytron seems that feature is developed, but it is not configurable from server configuration. Legacy security solution allows to configure search time limit for searching LDAP through searchTimeLimit option from LdapExtLoginModule.
> Since this feature was provided by legacy solution it should be also available in Elytron.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1980) Property file passed via CLI does not resolve expressions with relative path value in vault attributes
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1980?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFCORE-1980:
-----------------------------------
As the example uses vault.keystore.url=${jboss.server.config.dir}/vault/vault.keystore in vault.properties.
CLIExpressionResolver tries to recursively resolve expression ${vault.keystore.url} in command
/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "${vault.keystore.url}"), ("KEYSTORE_PASSWORD" => "${vault.keystore.password}") ... ...
When it finds ${jboss.server.config.dir}/vault/vault.keystore in which jboss.server.config.dir can NOT be found in system properties in CLI side, but it is a legal property in server side.
Method resolveOrOriginal therefore catches UnresolvedExpressionException and returns the original value ${vault.keystore.url} for KEYSTORE_URL which causes the error.
> Property file passed via CLI does not resolve expressions with relative path value in vault attributes
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1980
> URL: https://issues.jboss.org/browse/WFCORE-1980
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha12
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Property file passed via CLI with --properties option does not resolve expressions in EAP 7, where in EAP 6 it works fine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7590) Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7590?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7590:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter
> ----------------------------------------------------------------------------
>
> Key: WFLY-7590
> URL: https://issues.jboss.org/browse/WFLY-7590
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> In Elytron subsystem there are attributes {{name-rewriter}} and {{final-name-rewriter}} which serves for the same purpose. Both of them are used for final name rewriting. It can be confusing when two different names are used for the same type of attribute.
> Attribute {{name-rewriter}} is used in:
> * {{realms}} attribute in {{security-domain}}
> Attribute {{final-name-rewriter}} is used in:
> * {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}}
> * {{mechanism-realm-configurations}} in {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}}
> Names of {{name-rewriter}} and {{final-name-rewriter}} should be unified for this resources in DMR and also in XSD.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7590) Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7590?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7590:
-------------------------------
Labels: user_experience (was: )
> Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter
> ----------------------------------------------------------------------------
>
> Key: WFLY-7590
> URL: https://issues.jboss.org/browse/WFLY-7590
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> In Elytron subsystem there are attributes {{name-rewriter}} and {{final-name-rewriter}} which serves for the same purpose. Both of them are used for final name rewriting. It can be confusing when two different names are used for the same type of attribute.
> Attribute {{name-rewriter}} is used in:
> * {{realms}} attribute in {{security-domain}}
> Attribute {{final-name-rewriter}} is used in:
> * {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}}
> * {{mechanism-realm-configurations}} in {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}}
> Names of {{name-rewriter}} and {{final-name-rewriter}} should be unified for this resources in DMR and also in XSD.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7590) Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7590:
----------------------------------
Summary: Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter
Key: WFLY-7590
URL: https://issues.jboss.org/browse/WFLY-7590
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In Elytron subsystem there are attributes {{name-rewriter}} and {{final-name-rewriter}} which serves for the same purpose. Both of them are used for final name rewriting. It can be confusing when two different names are used for the same type of attribute.
Attribute {{name-rewriter}} is used in:
* {{realms}} attribute in {{security-domain}}
Attribute {{final-name-rewriter}} is used in:
* {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}}
* {{mechanism-realm-configurations}} in {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}}
Names of {{name-rewriter}} and {{final-name-rewriter}} should be unified for this resources in DMR and also in XSD.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7589) Wrong description for injecting the same realm to Elytron security-domain in CLI
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7589?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7589:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Wrong description for injecting the same realm to Elytron security-domain in CLI
> --------------------------------------------------------------------------------
>
> Key: WFLY-7589
> URL: https://issues.jboss.org/browse/WFLY-7589
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> Adding the same realms to one Elytron security-domain is denied in CLI. However failure-description is wrong. See:
> {code}
> /subsystem=elytron/security-domain=securityDomain:add(realms=[{realm=ApplicationRealm},{realm=ApplicationRealm}],default-realm=ApplicationRealm)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY00002: Can not inject the same realm 'securityDomain' in a single security domain 'ApplicationRealm'.",
> "rolled-back" => true
> }
> {code}
> It should says: "WFLYELY00002: Can not inject the same realm 'ApplicationRealm' in a single security domain 'securityDomain'.".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7589) Wrong description for injecting the same realm to Elytron security-domain in CLI
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7589?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7589:
-------------------------------
Labels: user_experience (was: )
> Wrong description for injecting the same realm to Elytron security-domain in CLI
> --------------------------------------------------------------------------------
>
> Key: WFLY-7589
> URL: https://issues.jboss.org/browse/WFLY-7589
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> Adding the same realms to one Elytron security-domain is denied in CLI. However failure-description is wrong. See:
> {code}
> /subsystem=elytron/security-domain=securityDomain:add(realms=[{realm=ApplicationRealm},{realm=ApplicationRealm}],default-realm=ApplicationRealm)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY00002: Can not inject the same realm 'securityDomain' in a single security domain 'ApplicationRealm'.",
> "rolled-back" => true
> }
> {code}
> It should says: "WFLYELY00002: Can not inject the same realm 'ApplicationRealm' in a single security domain 'securityDomain'.".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7589) Wrong description for injecting the same realm to Elytron security-domain in CLI
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7589:
----------------------------------
Summary: Wrong description for injecting the same realm to Elytron security-domain in CLI
Key: WFLY-7589
URL: https://issues.jboss.org/browse/WFLY-7589
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Adding the same realms to one Elytron security-domain is denied in CLI. However failure-description is wrong. See:
{code}
/subsystem=elytron/security-domain=securityDomain:add(realms=[{realm=ApplicationRealm},{realm=ApplicationRealm}],default-realm=ApplicationRealm)
{
"outcome" => "failed",
"failure-description" => "WFLYELY00002: Can not inject the same realm 'securityDomain' in a single security domain 'ApplicationRealm'.",
"rolled-back" => true
}
{code}
It should says: "WFLYELY00002: Can not inject the same realm 'ApplicationRealm' in a single security domain 'securityDomain'.".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months