[JBoss JIRA] (WFLY-6706) Domain mode stack trace on session invalidate
by Robert Smith (JIRA)
[ https://issues.jboss.org/browse/WFLY-6706?page=com.atlassian.jira.plugin.... ]
Robert Smith commented on WFLY-6706:
------------------------------------
We have a logout page that invoke session.invalidate and redirects to an unreferenced logout page. This scheme works flawlessly in standalone mode. In domain mode we invariably receive the following stack trace:
2016-06-13 13:22:06,281 ERROR [stderr] (default task-35) Exception in thread "default task-35" java.lang.IllegalStateException: UT000010: Session not found 5PBmAc9WQDTrb98H2D3dC1VE20b2qJ7QPKaeJmme
2016-06-13 13:22:06,282 ERROR [stderr] (default task-35) at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:430)
2016-06-13 13:22:06,282 ERROR [stderr] (default task-35) at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123)
2016-06-13 13:22:06,282 ERROR [stderr] (default task-35) at org.jboss.weld.context.http.HttpSessionContextImpl.checkBeanIdentifierIndexConsistency(HttpSessionContextImpl.java:85)
2016-06-13 13:22:06,282 ERROR [stderr] (default task-35) at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:42)
2016-06-13 13:22:06,283 ERROR [stderr] (default task-35) at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:19)
2016-06-13 13:22:06,283 ERROR [stderr] (default task-35) at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:219)
2016-06-13 13:22:06,283 ERROR [stderr] (default task-35) at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:167)
2016-06-13 13:22:06,283 ERROR [stderr] (default task-35) at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
2016-06-13 13:22:06,284 ERROR [stderr] (default task-35) at io.undertow.servlet.spec.AsyncContextImpl.setupRequestContext(AsyncContextImpl.java:686)
2016-06-13 13:22:06,284 ERROR [stderr] (default task-35) at io.undertow.servlet.spec.AsyncContextImpl.onAsyncComplete(AsyncContextImpl.java:596)
2016-06-13 13:22:06,284 ERROR [stderr] (default task-35) at io.undertow.servlet.spec.AsyncContextImpl.access$100(AsyncContextImpl.java:71)
2016-06-13 13:22:06,284 ERROR [stderr] (default task-35) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:317)
2016-06-13 13:22:06,285 ERROR [stderr] (default task-35) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:464)
2016-06-13 13:22:06,285 ERROR [stderr] (default task-35) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:580)
2016-06-13 13:22:06,285 ERROR [stderr] (default task-35) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
2016-06-13 13:22:06,286 ERROR [stderr] (default task-35) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
2016-06-13 13:22:06,286 ERROR [stderr] (default task-35) at java.lang.Thread.run(Thread.java:745)
> Domain mode stack trace on session invalidate
> ---------------------------------------------
>
> Key: WFLY-6706
> URL: https://issues.jboss.org/browse/WFLY-6706
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management, Web (Undertow)
> Affects Versions: 9.0.2.Final
> Reporter: Robert Smith
> Assignee: Brian Stansberry
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6678) StackoverflowError ejbclientinvocationcontext
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6678?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-6678:
-------------------------------
Affects Version/s: 9.0.1.Final
> StackoverflowError ejbclientinvocationcontext
> ---------------------------------------------
>
> Key: WFLY-6678
> URL: https://issues.jboss.org/browse/WFLY-6678
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.1.Final
> Environment: wildfly 9.0.1, jdk 1.8
> Reporter: Jimmy Pannier
> Attachments: server.log
>
>
> Sometimes after few days i get an exception
> Here is a stacktrace.
> 2016-06-07 07:38:10,441 ERROR [org.jboss.as.ejb3.invocation] (default task-76) WFLYEJB0034: EJB Invocation failed on component StorageServiceImpl for method public abstract java.util.List com.inovelan.cloud.api.storage.service.dataset.IStorageEjbService.loadData(com.inovelan.cloud.api.storage.model.dto.dataset.LoadDataConfig): javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:153)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> .....
> Caused by: java.lang.StackOverflowError
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6678) StackoverflowError ejbclientinvocationcontext
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6678?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-6678:
------------------------------------
Looking at the code I don't see how it would end up in this situation, unless of course the interceptor chain itself has got (extremely) long. So I see this in the code you pasted in the reproducer:
{code}
/**
* Get service needed authentication
*
* @param userContext
* @return
*/
public T getService(final String fullUserId, final String applicationName) {
try {
final Properties ejbClientContextProps = new Properties();
ejbClientContextProps.put("org.jboss.ejb.client.scoped.context", "true");
final Context initialContext = new InitialContext(ejbClientContextProps);
EJBClientContext.requireCurrent().registerInterceptor(0x99999, new ProxyInterceptor(fullUserId, applicationName));
return (T) initialContext.lookup(jndiName);
}
catch (NamingException e) {
LOGGER.warn("Service non disponible : " + jndiName + ", " + e);
}
return null;
}
{code}
I don't know, how/where that method of your application gets called from. But this specific statement in there:
{code}
EJBClientContext.requireCurrent().registerInterceptor(0x99999, new ProxyInterceptor(fullUserId, applicationName));
{code}
looks really suspicious. So you could be enrolling a new instance of the interceptor to the same EJBClientContext repeatedly, every single time (invocation?). Within the EJBClient library we _don't_ have a check to error out in cases where more than one interceptor instance is added to the same priority. So essentially this can lead to multiple instances of that interceptor to end up being put in the interceptor chain of that invocation and lead to an extremely long chain. This theory also fits in with what you say in your description:
{quote}
Sometimes after few days i get an exception
{quote}
So I would suggest, you change that code above to register that interceptor only once per EJBClientContext. Without knowing/seeing more context for that code of your application, I can't suggest where/how to do that such that it registers it only one per context.
> StackoverflowError ejbclientinvocationcontext
> ---------------------------------------------
>
> Key: WFLY-6678
> URL: https://issues.jboss.org/browse/WFLY-6678
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: wildfly 9.0.1, jdk 1.8
> Reporter: Jimmy Pannier
> Attachments: server.log
>
>
> Sometimes after few days i get an exception
> Here is a stacktrace.
> 2016-06-07 07:38:10,441 ERROR [org.jboss.as.ejb3.invocation] (default task-76) WFLYEJB0034: EJB Invocation failed on component StorageServiceImpl for method public abstract java.util.List com.inovelan.cloud.api.storage.service.dataset.IStorageEjbService.loadData(com.inovelan.cloud.api.storage.model.dto.dataset.LoadDataConfig): javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:153)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> .....
> Caused by: java.lang.StackOverflowError
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6703) Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6703?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-6703:
-----------------------------------
Hi [~rhusar]
I suppose it's happening on current WF 10.1.0.Final-SNAPSHOT right? Or is it reproducible on WF 10.0.0.Final as well? I was experimenting locally with WF 10.1.0.Final-SNAPSHOT and haven't been able to reproduce it yet. Do you use some special configuration of Infinispan or JGroups please or do you use the default one? What's the probability of this intermittent failure?
Looking at related Weld code it looks like it's getting different http session (from {{request.getSession(false);}}) which is weird..
> Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6703
> URL: https://issues.jboss.org/browse/WFLY-6703
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Radoslav Husar
> Assignee: Tomas Remes
>
> 13:57:41,855 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /clusterbench/session: org.jboss.weld.exceptions.IllegalStateException: WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> Expected hash: 1931672237
> Current index: BeanIdentifierIndex [hash=1185198536, indexed=13]
> 0: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-ejb.jar%HttpSession
> 1: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war%HttpSession
> 2: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-granular.war%HttpSession
> 3: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war%HttpSession
> 4: WELD%AbstractBuiltInBean%clusterbench-ee7.ear%HttpSession
> 5: WELD%AbstractBuiltInBean%com.sun.jsf-impl:main.additionalClasses%HttpSession
> 6: WELD%AbstractBuiltInBean%org.hibernate.validator.cdi:main.additionalClasses%HttpSession
> 7: WELD%AbstractBuiltInBean%org.jberet.jberet-core:main.additionalClasses%HttpSession
> 8: WELD%AbstractBuiltInBean%org.jboss.as.jsf:main.additionalClasses%HttpSession
> 9: WELD%AbstractBuiltInBean%org.jboss.resteasy.resteasy-cdi:main.additionalClasses%HttpSession
> 10: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 11: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 12: WELD%SessionBean%LocalStatefulSB%org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB
> 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:245)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
> 13:57:41,941 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel server: [node1|2] (1) [node1]
> 13:57:41,942 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel web: [node1|2] (1) [node1]
> 13:57:41,943 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel hibernate: [node1|2] (1) [node1]
> 13:57:41,944 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel ejb: [node1|2] (1) [node1]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6703) Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6703?page=com.atlassian.jira.plugin.... ]
Tomas Remes reassigned WFLY-6703:
---------------------------------
Assignee: Tomas Remes (was: Martin Kouba)
> Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6703
> URL: https://issues.jboss.org/browse/WFLY-6703
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Radoslav Husar
> Assignee: Tomas Remes
>
> 13:57:41,855 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /clusterbench/session: org.jboss.weld.exceptions.IllegalStateException: WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> Expected hash: 1931672237
> Current index: BeanIdentifierIndex [hash=1185198536, indexed=13]
> 0: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-ejb.jar%HttpSession
> 1: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war%HttpSession
> 2: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-granular.war%HttpSession
> 3: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war%HttpSession
> 4: WELD%AbstractBuiltInBean%clusterbench-ee7.ear%HttpSession
> 5: WELD%AbstractBuiltInBean%com.sun.jsf-impl:main.additionalClasses%HttpSession
> 6: WELD%AbstractBuiltInBean%org.hibernate.validator.cdi:main.additionalClasses%HttpSession
> 7: WELD%AbstractBuiltInBean%org.jberet.jberet-core:main.additionalClasses%HttpSession
> 8: WELD%AbstractBuiltInBean%org.jboss.as.jsf:main.additionalClasses%HttpSession
> 9: WELD%AbstractBuiltInBean%org.jboss.resteasy.resteasy-cdi:main.additionalClasses%HttpSession
> 10: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 11: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 12: WELD%SessionBean%LocalStatefulSB%org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB
> 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:245)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
> 13:57:41,941 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel server: [node1|2] (1) [node1]
> 13:57:41,942 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel web: [node1|2] (1) [node1]
> 13:57:41,943 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel hibernate: [node1|2] (1) [node1]
> 13:57:41,944 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel ejb: [node1|2] (1) [node1]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-467) Integrate CredentialStore with mechanism configuration so mechanisms can obtain the credentials they require.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-467?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-467:
--------------------------------------
We have decided to implement this by making use of a reference to a SecurityFactory<Credential> - however we could still add a SecurityFactory implementation that contains a reference to a CredentialStore and the name of the alias it should use.
e.g. the CredentialStore interface could have a method like the following: -
static SecurityFactory<Credential> toSecurityFactory(String alias, Class<? extends Credential> type);
> Integrate CredentialStore with mechanism configuration so mechanisms can obtain the credentials they require.
> -------------------------------------------------------------------------------------------------------------
>
> Key: ELY-467
> URL: https://issues.jboss.org/browse/ELY-467
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: API / SPI, Credential Store
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta6
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-460) Switchable Nonce Handling Strategy for HTTP DigestAuthenticator
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-460?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse resolved WFLY-460.
-----------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Out of Date
Current authenticators and authentication mechanisms are deprecated - switching to WildFly Elytron which will have it's own nonce handling strategy.
> Switchable Nonce Handling Strategy for HTTP DigestAuthenticator
> ---------------------------------------------------------------
>
> Key: WFLY-460
> URL: https://issues.jboss.org/browse/WFLY-460
> Project: WildFly
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Common_Authentication
> Fix For: 10.1.0.Final
>
>
> Allow the nonce strategy to be switchable: -
> 1 - Real 'Number Used Once' - i.e. new nonce for each request.
> 2 - Nonce per connection i.e. as long as a connection is kept alive allow re-use of nonce - new nonce on new connection.
> 3 - Timed nonce - Generate a nonce with a server secret and timestamp, nonce will be accepted for a validity period.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5894) Usage of context.getOriginalRootResource().navigate(pathAddress) should be reviewed in the picketlink subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5894?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-5894:
--------------------------------------
Assignee: Pedro Igor (was: Darran Lofthouse)
> Usage of context.getOriginalRootResource().navigate(pathAddress) should be reviewed in the picketlink subsystem
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5894
> URL: https://issues.jboss.org/browse/WFLY-5894
> Project: WildFly
> Issue Type: Task
> Components: Security
> Reporter: James Perkins
> Assignee: Pedro Igor
>
> There are 4 resource definitions that use the {{OperationContext.getOriginalRootResource()}} method. These could be fragile in a composite add/write operation as a {{NoSuchResourceException}} might be thrown during the {{Resource.navigate()}} method.
> 1. {{org.wildfly.extension.picketlink.federation.model.idp.IdentityProviderResourceDefinition}}
> 2. {{org.wildfly.extension.picketlink.federation.model.keystore.KeyStoreProviderResourceDefinition}}
> 3. {{org.wildfly.extension.picketlink.federation.model.saml.SAMLResourceDefinition}}
> 4. {{org.wildfly.extension.picketlink.federation.model.sp.ServiceProviderResourceDefinition}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months