[JBoss JIRA] (WFLY-4423) ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4423?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4423:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1201358|https://bugzilla.redhat.com/show_bug.cgi?id=1201358] from VERIFIED to CLOSED
> ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
> ----------------------------------------------------------------------------
>
> Key: WFLY-4423
> URL: https://issues.jboss.org/browse/WFLY-4423
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> To reproduce this issue follow the steps:
> - setup JMS bridge between two WildFly instances
> - once JMS bridge is running, login into jboss-cli and stop the bridge
> - restart the bridge fro jboss-cli
> The following exception appears in the serve log file.
> 10:12:59,414 INFO [org.hornetq.jms.server] (pool-9-thread-1) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 60,000 ms
> 10:13:59,416 WARN [org.hornetq.jms.server] (pool-9-thread-1) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:126)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_75]
> at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55)
> at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1236)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1474)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2200(JMSBridgeImpl.java:79)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2082)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_75]
> at java.lang.Class.forName(Class.java:274) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:121)
> ... 17 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-668) Make the INFO logging from deprecated attributes configurable, also improve the message
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-668?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-668:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1213421|https://bugzilla.redhat.com/show_bug.cgi?id=1213421] from VERIFIED to CLOSED
> Make the INFO logging from deprecated attributes configurable, also improve the message
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-668
> URL: https://issues.jboss.org/browse/WFCORE-668
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Final, 2.0.0.Alpha3
>
>
> The INFO logging that AttributeDefinition generates when a deprecated attribute is used needs to be configurable, i.e. with a boolean flag so a dev can turn it off for attributes where it serves no purpose.
> The logging only serves a purpose if an admin can take action to use some alternative config. If an attribute is deprecated only because in some future release it will go away, but there's no replacement now, the logging is just noise.
> The log message itself should be improved:
> 1) Get rid of the ! at the end. It's not that exciting. ;)
> 2) Include the address of the resource
> 3) Point the user at the read-resource-description output from which they can learn more about the deprecation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-4625) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4625?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4625:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1243553|https://bugzilla.redhat.com/show_bug.cgi?id=1243553] from VERIFIED to CLOSED
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4625
> URL: https://issues.jboss.org/browse/WFLY-4625
> Project: WildFly
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
> Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-855) Intermittent Disconnection from CLI After Reload in domain mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-855?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-855:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1249031|https://bugzilla.redhat.com/show_bug.cgi?id=1249031] from VERIFIED to CLOSED
> Intermittent Disconnection from CLI After Reload in domain mode
> ---------------------------------------------------------------
>
> Key: WFCORE-855
> URL: https://issues.jboss.org/browse/WFCORE-855
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha12
> Reporter: Joe Wertz
> Assignee: Joe Wertz
> Fix For: 2.0.0.Alpha13
>
> Original Estimate: 3 minutes
> Time Spent: 3 hours
> Remaining Estimate: 0 minutes
>
> Description of problem:
> CLI scripts for management of managed domain
> Version-Release number of selected component (if applicable):
> 6.4.3.CP.CR1
> How reproducible:
> Always
> Steps to Reproduce:
> Use CLI script:
> :read-attribute(name=process-type)
> reload --host=master
> :read-attribute(name=process-type)
> or commands option for script
> Actual results:
> 6.4.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Failed to establish connection in 6025ms
> Expected results:
> 6.3.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Additional info:
> - Follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1232933
> - using --timeout doesn't workaround the problem
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-4188) Client Mapping expressions are allowed but are not resolved if used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4188?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4188:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1175442|https://bugzilla.redhat.com/show_bug.cgi?id=1175442] from VERIFIED to CLOSED
> Client Mapping expressions are allowed but are not resolved if used
> -------------------------------------------------------------------
>
> Key: WFLY-4188
> URL: https://issues.jboss.org/browse/WFLY-4188
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Chao Wang
> Fix For: 9.0.0.Beta1
>
>
> If socket binding with client-mapping is used to provide a valid client address for EJB invocation to the client the expressions are not resolved.
> Depend on the attribute the parsing failed direct during startup (port# is not numeric) or the expression is send to the client where the Exception is thrown at runtime.
> Notice for EJB invocation the problem is only visible if the application is clustered, otherwise the cluster view (where the client-mapping take effect) is not send to the client.
> Dec 17, 2014 2:53:43 PM org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager getEJBReceiver
> INFO: Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='redhat', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}', destinationPort=8080}], resolvedDestination=[Destination address=${jboss.node.name}, destination port=8080]} in cluster ejb
> java.lang.RuntimeException: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
> ... 8 more
> Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at java.net.URI$Parser.fail(URI.java:2829)
> at java.net.URI$Parser.parseAuthority(URI.java:3167)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3034)
> at java.net.URI.<init>(URI.java:680)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> ... 12 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7754) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-7754?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-7754:
------------------------------------
Nearby I see:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-41) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concu
rrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key SessionCreationMetaDataKey(-FZZqY7ngjgP3-RbfmHcXh-2NWGA2HIPaxcumCPy) and requestor GlobalTransaction:<null>:7:local. Lock i
s held by GlobalTransaction:<null>:3:local
at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:238)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:193)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:193)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:116)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:71)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:80)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:70)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:60)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:59)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:38)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:233)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:148)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:772)
at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:234)
at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
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 io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
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:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
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)
> WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
> ----------------------------------------------------------------------------
>
> Key: WFLY-7754
> URL: https://issues.jboss.org/browse/WFLY-7754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
>
> When modifying the WELD bean profile between starting/stopping WildFly with persistent session cookies over restart enabled.
> It is possible to get an unrecoverable o.j.w.e.IllegalStateException.
> What I mean by this is that if the AS knows the HTTP session cookie is a valid ID, but is unable to recover it from the persistence serialization over a restart (due to a change in the WELD BeanIdentifer instances changing to allow the optimization to work in this area). What the AS should do is simply log the problem and invalidate the session cookie completely. All this should happen in a transparent way to the WebApp, so it gets a null return or a brand new HttpSession.
> This will automatically allow the HTTP client to recover, by forcing the application to generate a new HTTP session as necessary / or force logout, etc..
> This is unrecoverable since the exception seems to be thrown at a level before it hits any WebApp application code. So it doesn't seem possible for the WebApp developer to correct the problem from the exception. Which makes sense since you need a HttpSession object to invoke #invalidate() on and it is recovering that that is.
> Everytime the user refreshes all they get is the error and a HTTP/500 Internal Server Error and the user has to either delete their cookie, or the WildFly admin shutdown and remove any persistent session cookie data.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7754) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-7754?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-7754:
------------------------------------
ERROR [io.undertow.request] (default task-17) UT005023: Exception handling request to /main/systema/process.cgi: org.jboss.weld.exceptions.IllegalStateException: WELD-0002
Expected hash: 385344494
Current index: BeanIdentifierIndex [hash=-1454573931, indexed=23]
0: WELD%AbstractBuiltInBean%/content/com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.abc-0.0.1-SNAPSHOT.jar%HttpSession
1: WELD%AbstractBuiltInBean%com.sun.jsf-impl:main.additionalClasses%HttpSession
2: WELD%AbstractBuiltInBean%org.hibernate.validator.cdi:main.additionalClasses%HttpSession
3: WELD%AbstractBuiltInBean%org.jberet.jberet-core:main.additionalClasses%HttpSession
4: WELD%AbstractBuiltInBean%org.jboss.as.jsf:main.additionalClasses%HttpSession
5: WELD%AbstractBuiltInBean%org.jboss.jts:main.additionalClasses%HttpSession
6: WELD%AbstractBuiltInBean%org.jboss.resteasy.resteasy-cdi:main.additionalClasses%HttpSession
7: WELD%AbstractBuiltInBean%org.wildfly.extension.messaging-activemq:main.additionalClasses%HttpSession
8: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear%HttpSession
9: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.aspnetdb-0.0.1-SNAPSHOT.jar/%HttpSession
10: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.common-0.0.1-SNAPSHOT.jar/%HttpSession
11: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.experimental-0.0.1-SNAPSHOT.jar/%HttpSession
12: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.incubation-0.0.1-SNAPSHOT.jar/%HttpSession
13: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.kernel-0.0.1-SNAPSHOT.jar/%HttpSession
14: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.kernel.main-0.0.1-SNAPSHOT.jar/%HttpSession
15: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.main-0.0.1-SNAPSHOT.jar/%HttpSession
16: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.systema-0.0.1-SNAPSHOT.jar/%HttpSession
17: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.security-0.0.1-SNAPSHOT.jar/%HttpSession
18: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.thirdparty-0.0.1-SNAPSHOT.jar/%HttpSession
19: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-ejb.websupps-0.0.1-SNAPSHOT.jar/%HttpSession
20: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-webapp.main-0.0.1-SNAPSHOT.war%HttpSession
21: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-webapp.publicapi-0.0.1-SNAPSHOT.war%HttpSession
22: WELD%AbstractBuiltInBean%com.mydomain.ear-0.0.1-SNAPSHOT.ear/com-mydomain-webapp.support-0.0.1-SNAPSHOT.war%HttpSession
at org.jboss.weld.context.http.HttpSessionContextImpl.checkBeanIdentifierIndexConsistency(HttpSessionContextImpl.java:101)
at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:47)
at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:23)
at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:237)
at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
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 io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
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:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
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)
> WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
> ----------------------------------------------------------------------------
>
> Key: WFLY-7754
> URL: https://issues.jboss.org/browse/WFLY-7754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
>
> When modifying the WELD bean profile between starting/stopping WildFly with persistent session cookies over restart enabled.
> It is possible to get an unrecoverable o.j.w.e.IllegalStateException.
> What I mean by this is that if the AS knows the HTTP session cookie is a valid ID, but is unable to recover it from the persistence serialization over a restart (due to a change in the WELD BeanIdentifer instances changing to allow the optimization to work in this area). What the AS should do is simply log the problem and invalidate the session cookie completely. All this should happen in a transparent way to the WebApp, so it gets a null return or a brand new HttpSession.
> This will automatically allow the HTTP client to recover, by forcing the application to generate a new HTTP session as necessary / or force logout, etc..
> This is unrecoverable since the exception seems to be thrown at a level before it hits any WebApp application code. So it doesn't seem possible for the WebApp developer to correct the problem from the exception. Which makes sense since you need a HttpSession object to invoke #invalidate() on and it is recovering that that is.
> Everytime the user refreshes all they get is the error and a HTTP/500 Internal Server Error and the user has to either delete their cookie, or the WildFly admin shutdown and remove any persistent session cookie data.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months