[JBoss JIRA] (ELY-923) Elytron LDAP caching realm should cache attributes and credentials
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/ELY-923?page=com.atlassian.jira.plugin.sy... ]
Ondrej Kotek moved JBEAP-8680 to ELY-923:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-923 (was: JBEAP-8680)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Realms
(was: Security)
Affects Version/s: 1.1.0.Beta21
(was: 7.1.0.DR11)
> Elytron LDAP caching realm should cache attributes and credentials
> ------------------------------------------------------------------
>
> Key: ELY-923
> URL: https://issues.jboss.org/browse/ELY-923
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta21
> Reporter: Ondrej Kotek
> Priority: Blocker
>
> Elytron {{caching-realm}} backed by {{ldap-realm}} provides caching for identity objects but not for related credentials and attributes. This is currently due to design of {{ldap-realm}} (like in case of {{filesystem-realm}}, see ELY-915).
> Credentials and attributes should not be loaded from LDAP for a cache hit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-896) NPE in server log if client's password is null
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-896?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-896:
---------------------------------
Fix Version/s: 1.1.0.Beta23
> NPE in server log if client's password is null
> -----------------------------------------------
>
> Key: ELY-896
> URL: https://issues.jboss.org/browse/ELY-896
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Passwords
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta23
>
>
> If standalone JMS client creates connection with username and password where password is {{null}} like:
> {code}
> connectionFactory.createConnection("admin", null);
> {code}
> then server logs NPE:
> {code}
> 13:24:10,567 ERROR [org.apache.activemq.artemis.core.server] (default I/O-6) AMQ224018: Failed to create session: java.lang.NullPointerException
> at java.util.Arrays.fill(Arrays.java:2951) [rt.jar:1.8.0_71]
> at org.wildfly.security.evidence.PasswordGuessEvidence.destroy(PasswordGuessEvidence.java:53) [wildfly-elytron-1.1.0.Beta16.jar:1.1.0.Beta16]
> at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.authenticate(ElytronSecurityManager.java:107)
> at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.validateUser(ElytronSecurityManager.java:62)
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:132)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1205)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1128)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> {code}
> Server should log the same error as if wrong password is provided:
> {code}
> 13:23:38,713 ERROR [org.apache.activemq.artemis.core.server] (default I/O-6) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1205)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1128)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8030) Elytron ldap-realm does not handle loops in referrals
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-8030?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved ELY-922 to WFLY-8030:
--------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-8030 (was: ELY-922)
Component/s: Security
(was: Realms)
Affects Version/s: (was: 1.1.0.Beta21)
> Elytron ldap-realm does not handle loops in referrals
> -----------------------------------------------------
>
> Key: WFLY-8030
> URL: https://issues.jboss.org/browse/WFLY-8030
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-921) Elytron FORM authentication failing if TRACE is enabled.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-921?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-921:
---------------------------------
Fix Version/s: 1.1.0.Beta23
> Elytron FORM authentication failing if TRACE is enabled.
> --------------------------------------------------------
>
> Key: ELY-921
> URL: https://issues.jboss.org/browse/ELY-921
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.1.0.Beta22
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta23
>
> Attachments: secured-webapp.war.zip
>
>
> NPE occures during FORM authentication when TRACE logging is enabled.
> {code}
> 11:02:55,488 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /secured-webapp/: java.lang.NullPointerException
> at org.wildfly.elytron.web.undertow.server.ElytronHttpExchange$4.getID(ElytronHttpExchange.java:401)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptReAuthentication(FormAuthenticationMechanism.java:228)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:99)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:210)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code:java|title=FormAuthenticationMechanism.java}
> if (log.isTraceEnabled()) {
> if (getSessionScope(request, false) != null) {
> log.tracef("Trying to re-authenticate session %s using FormAuthenticationMechanism. Request URI: [%s], Context path: [%s]",
> getSessionScope(request, false).getID(), request.getRequestURI(), this.contextPath);
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-922) Elytron ldap-realm does not handle loops in referrals
by Jan Kalina (JIRA)
Jan Kalina created ELY-922:
------------------------------
Summary: Elytron ldap-realm does not handle loops in referrals
Key: ELY-922
URL: https://issues.jboss.org/browse/ELY-922
Project: WildFly Elytron
Issue Type: Bug
Components: Realms
Affects Versions: 1.1.0.Beta21
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Critical
According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
[1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-918) Allow HTTP mechanisms to decide if response should be sent when authentication is in progress
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-918?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor closed ELY-918.
--------------------------
Resolution: Rejected
> Allow HTTP mechanisms to decide if response should be sent when authentication is in progress
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-918
> URL: https://issues.jboss.org/browse/ELY-918
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.1.0.Beta21
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> Currently, mechanisms are not allowed to decide if a challenge should be sent or not when processing a request to path where authentication is not required.
> Currently, we always write to the response regardless if authentication if required or not, making impossible to mechanisms decide what you do in cases where a request is a for a non-protected resource and an authentication challenge should not be sent.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-921) Elytron FORM authentication failing if TRACE is enabled.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-921?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse moved WFLY-7978 to ELY-921:
--------------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-921 (was: WFLY-7978)
Component/s: HTTP
(was: Security)
Affects Version/s: 1.1.0.Beta22
(was: 11.0.0.Alpha1)
> Elytron FORM authentication failing if TRACE is enabled.
> --------------------------------------------------------
>
> Key: ELY-921
> URL: https://issues.jboss.org/browse/ELY-921
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.1.0.Beta22
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: secured-webapp.war.zip
>
>
> NPE occures during FORM authentication when TRACE logging is enabled.
> {code}
> 11:02:55,488 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /secured-webapp/: java.lang.NullPointerException
> at org.wildfly.elytron.web.undertow.server.ElytronHttpExchange$4.getID(ElytronHttpExchange.java:401)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptReAuthentication(FormAuthenticationMechanism.java:228)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:99)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:210)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code:java|title=FormAuthenticationMechanism.java}
> if (log.isTraceEnabled()) {
> if (getSessionScope(request, false) != null) {
> log.tracef("Trying to re-authenticate session %s using FormAuthenticationMechanism. Request URI: [%s], Context path: [%s]",
> getSessionScope(request, false).getID(), request.getRequestURI(), this.contextPath);
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ]
Peter Palaga resolved WFLY-4539.
--------------------------------
Resolution: Done
Resolved by the upgrade to remoting 5.0.0.Beta13 that happened some time ago
> logging statement to trace remoting heartbeat
> ---------------------------------------------
>
> Key: WFLY-4539
> URL: https://issues.jboss.org/browse/WFLY-4539
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Carsten Lichy-Bittendorf
> Assignee: Peter Palaga
> Priority: Minor
>
> you can set the heartbeat on a remoting connection by setting:
> remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
> What is missing is the option to log on the client when the heartbeat message is fired.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months