[JBoss JIRA] (SECURITY-859) Authentication failure due to a login module misconfiguration is not reported if principal is null
by Ivo Studensky (JIRA)
Ivo Studensky created SECURITY-859:
--------------------------------------
Summary: Authentication failure due to a login module misconfiguration is not reported if principal is null
Key: SECURITY-859
URL: https://issues.jboss.org/browse/SECURITY-859
Project: PicketBox
Issue Type: Bug
Components: PicketBox
Affects Versions: PicketBox_4_0_19.SP5, PicketBox_4_0_21.Beta2
Reporter: Ivo Studensky
Assignee: Peter Skopek
Any misconfiguration of a login module leading to authentication failure used to be reported at trace level for anonymous user (principal == null) until SECURITY-660. Right now it is reported at debug level, but only if principal != null.
I am going to propose a fix to report the cause of such a failure at debug level despite the principal value. So that customers can see for example "javax.security.auth.login.LoginException: unable to find LoginModule class: ..." in their logs instead of "PBOX000016: Access denied" only.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3846) JMS resources allows duplicate JNDI entries
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-3846:
---------------------------------
Summary: JMS resources allows duplicate JNDI entries
Key: WFLY-3846
URL: https://issues.jboss.org/browse/WFLY-3846
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 8.1.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 9.0.0.Alpha1
The JMS resources that can be stored in JNDI (connection-factory, pooled-connection-factory, jms-queue, jms-topic) does not check whether their list of JNDI entries contains duplicates.
At runtime, duplicates are eliminated but this introduces a difference between the resource model with duplicate entries and its runtime state (without duplicates).
The attribute definitions for their JNDI entries should validate at the MODEL stage that their value does not contain duplicate elements.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3796) org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-3796?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-3796:
------------------------------------
[~juergen.zimmermann] I was trying to reproduce this issue and found out that the same error occurs if {{UIViewRoot.getViewMap().clear()}} is invoked before {{HttpSession.invalidate()}}.
When {{UIViewRoot.getViewMap().clear()}} is invoked, the {{PreDestroyViewMapEvent}} is published and the listener of this event finally calls {{ViewScopeContextManager.destroyBeans()}}. So my guess is there is something in your application which invokes the aforementioned method before the HTTP session is invalidated, and in the end {{ViewScopeContextManager.destroyBeans()}} is invoked twice.
Also, it seems it's picketlink unrelated.
> org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
> --------------------------------------------------------------------------------
>
> Key: WFLY-3796
> URL: https://issues.jboss.org/browse/WFLY-3796
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 9.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
>
> I'm using WildFly 9.0.0.Alpha1 snapshot. When I invoke HttpSession.invalidate() after PicketLink's logout method I'm getting a org.jboss.weld.exceptions.IllegalArgumentException (see stacktrace below). I also tried weld-core-impl-2.2.4.Final, but got the same stacktrace.
> The Session Bean "ListKundenModel" has these annotations:
> @Named
> @ViewScoped
> @Stateful
> {code}
> WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] #{logoutModel.logout}: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]: javax.faces.FacesException: #{logoutModel.logout}: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: javax.faces.el.EvaluationException: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.8-jbossorg-1.jar:]
> ... 33 more
> Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at org.jboss.weld.bean.SessionBean.destroy(SessionBean.java:155) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.sun.faces.application.view.ViewScopeContextManager.destroyBeans(ViewScopeContextManager.java:177) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.view.ViewScopeContextManager.sessionDestroyed(ViewScopeContextManager.java:339) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.view.ViewScopeManager.sessionDestroyed(ViewScopeManager.java:371) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.WebappLifecycleListener.sessionDestroyed(WebappLifecycleListener.java:181) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigureListener.sessionDestroyed(ConfigureListener.java:377) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:264) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:66) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:56) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:395) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:381) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:197) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at de.shop.iam.web.LogoutModel.logout(LogoutModel.java:55) [classes:]
> at de.shop.iam.web.LogoutModel$Proxy$_$$_WeldSubclass.logout(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.interceptorChainCompleted(SimpleInterceptionChain.java:51) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:96) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:149) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at de.shop.util.interceptor.LogInterceptor.log(LogInterceptor.java:96) [classes:]
> at sun.reflect.GeneratedMethodAccessor2531.invoke(Unknown Source) [:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:149) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) [narayana-jts-jacorb-5.0.2.Final.jar:5.0.2.Final (revision: d1e56)]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.2.Final.jar:5.0.2.Final (revision: d1e56)]
> at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source) [:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at de.shop.iam.web.LogoutModel$Proxy$_$$_WeldSubclass.logout(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at com.sun.el.parser.AstValue.invoke(AstValue.java:292) [javax.el-impl-3.0.1-b05-jbossorg-1.jar:3.0.1-b05-jbossorg-1]
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-impl-3.0.1-b05-jbossorg-1.jar:3.0.1-b05-jbossorg-1]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> ... 34 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Theo Gülcher (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Theo Gülcher edited comment on WFLY-3664 at 9/11/14 4:20 AM:
-------------------------------------------------------------
I also have this issue in our web application (no webstart/JNLP though):
Caused by: java.lang.IllegalStateException: UT010019: Response already commited
at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:116) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:158) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:158) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.context.ExternalContextImpl.responseSendError(ExternalContextImpl.java:949) [jsf-impl-2.2.6-jbossorg-4.jar:]
at javax.faces.context.ExternalContextWrapper.responseSendError(ExternalContextWrapper.java:916) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at org.jboss.seam.faces.environment.SeamExternalContext$Proxy$_$$_WeldClientProxy.responseSendError(Unknown Source) [seam-faces-3.1.0.Final.jar:3.1.0.Final]
at com.sun.faces.application.view.MultiViewHandler.send404Error(MultiViewHandler.java:758) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:589) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.MultiViewHandler.createView(MultiViewHandler.java:167) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.ocpsoft.pretty.faces.application.PrettyViewHandler.createView(PrettyViewHandler.java:100) [prettyfaces-jsf2-3.3.3.jar:]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:254) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
... 58 more
was (Author: gulcher):
I also have this issue in our application:
Caused by: java.lang.IllegalStateException: UT010019: Response already commited
at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:116) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:158) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:158) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.context.ExternalContextImpl.responseSendError(ExternalContextImpl.java:949) [jsf-impl-2.2.6-jbossorg-4.jar:]
at javax.faces.context.ExternalContextWrapper.responseSendError(ExternalContextWrapper.java:916) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at org.jboss.seam.faces.environment.SeamExternalContext$Proxy$_$$_WeldClientProxy.responseSendError(Unknown Source) [seam-faces-3.1.0.Final.jar:3.1.0.Final]
at com.sun.faces.application.view.MultiViewHandler.send404Error(MultiViewHandler.java:758) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:589) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.MultiViewHandler.createView(MultiViewHandler.java:167) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.ocpsoft.pretty.faces.application.PrettyViewHandler.createView(PrettyViewHandler.java:100) [prettyfaces-jsf2-3.3.3.jar:]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:254) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
... 58 more
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: demo-src.zip, server.log
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Theo Gülcher (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Theo Gülcher commented on WFLY-3664:
------------------------------------
I also have this issue in our application:
Caused by: java.lang.IllegalStateException: UT010019: Response already commited
at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:116) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:158) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:158) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.context.ExternalContextImpl.responseSendError(ExternalContextImpl.java:949) [jsf-impl-2.2.6-jbossorg-4.jar:]
at javax.faces.context.ExternalContextWrapper.responseSendError(ExternalContextWrapper.java:916) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at org.jboss.seam.faces.environment.SeamExternalContext$Proxy$_$$_WeldClientProxy.responseSendError(Unknown Source) [seam-faces-3.1.0.Final.jar:3.1.0.Final]
at com.sun.faces.application.view.MultiViewHandler.send404Error(MultiViewHandler.java:758) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:589) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.MultiViewHandler.createView(MultiViewHandler.java:167) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.ocpsoft.pretty.faces.application.PrettyViewHandler.createView(PrettyViewHandler.java:100) [prettyfaces-jsf2-3.3.3.jar:]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.createView(ViewHandlerWrapper.java:173) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:254) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
... 58 more
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: demo-src.zip, server.log
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-9) Exception in User-defined Java method when rules are optimized by the JIT compiler
by Sarf Khan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-9?page=com.atlassian.jira.plugin.s... ]
Sarf Khan commented on DROOLS-9:
--------------------------------
[~mfusco]
I'm new to drools and am facing a similar issue. I am not able to fully comprehend the comments given by you.
So I have few queries regarding mentioned exception.
1. Does this exception cause or halt the rule execution?
2. If yes, how to avoid it?
3. Do you recommend some changes in the expression?
My drools expression in application looks like this:
"(this.operator == 'BWH' && this.handlingExceptiondesc=='DLY' && $recTrnd.delay!=null && $recTrnd.delay > this.minVal && $recTrnd.delay <= this.maxVal)"
And the stack trace of the exception thrown is similar to the above stack trace. and it looks like
.....RecTrndFact.getDelay: target of method is null
at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:66)
at org.mvel2.optimizers.impl.refl.nodes.VariableAccessor.getValue(VariableAccessor.java:37)
at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:108)
at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
at org.mvel2.ast.And.getReducedValueAccelerated(And.java:34)
at org.mvel2.ast.And.getReducedValueAccelerated(And.java:34)
at org.mvel2.ast.And.getReducedValueAccelerated(And.java:34)
at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
> Exception in User-defined Java method when rules are optimized by the JIT compiler
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-9
> URL: https://issues.jboss.org/browse/DROOLS-9
> Project: Drools
> Issue Type: Bug
> Reporter: Andreas Bentele
> Assignee: Mario Fusco
> Attachments: DroolsJITTestCase.zip
>
>
> I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
> I didn't find any trivial example, so I reproduced the error with a non-trivial test case derived from a real-live rule, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
> What does the application:
> - it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
> - after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
> - this service is called in the LHS of the rule
> But:
> # in the rule, the following expression evaluates always to false, because service.getLongValue returns always 0
> {code}
> $service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0
> {code}
> # from this and rule semantics it follows that the next expression should never be evaluated, but the JIT compiler evaluates it:
> {code}
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> {code}
> # as we have seen in the bullet no. 1, the parameter of service.getTimePerStroke is 0. In com.sample.Service, Line 41 the parameter value is asserted to be not 0, so an RuntimeException is thrown (Line 42).
> Code of the rule:
> {code}
> rule "DroolsJITTest-Rule"
> when
> $service : Service()
> p: PulseEvent(
> $actionTimestamp : actionTimestamp,
> $eventTimestamp : eventTimestamp
> )
> t: TimerToken(
> $machineId : id,
> $timestampUTC : timestampUTC,
> $service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> ) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
> then
> System.out.println( "Rule executed" );
> update(p);
> end
> {code}
> I think, it's a failure that the JIT compiler evaluates the line
> {code}
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> {code}
> because the previous condition expression evaluates to false. Or do you think this behavior works as designed?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3845) Share the same jsessionid in different context root
by Sandeep Samdaria (JIRA)
[ https://issues.jboss.org/browse/WFLY-3845?page=com.atlassian.jira.plugin.... ]
Sandeep Samdaria updated WFLY-3845:
-----------------------------------
Description:
I have two applications which need a Single Sign On. User once logged into an application should not need login again to another application.
To achieve that I was storing the session id in the cookie. The other application used to retrieve the session and verify the user.
Now, the problem that I am facing, after upgrading to wildfly, is that the each application is producing different jsessionid. I have also tried the workaround mentioned in https://issues.jboss.org/browse/WFLY-3617, but in vain.
I have deployed the same wars in jboss-eap-6.2 and that worked for me.
I have copied the two war over here https://www.dropbox.com/sh/cq5p373wasn5svj/AACyZaBMBCGaNMaBU8zbW82Za?dl=0
was:
I have two applications which need a Single Sign On. User once logged into an application should not need login again to another application.
To achieve that I was storing the session id in the cookie. The other application used to retrieve the session and verify the user.
Now, the problem that I am facing, after upgrading to wildfly, is that the each application is producing different jsessionid. I have also tried the workaround mentioned in https://issues.jboss.org/browse/WFLY-3617, but in vain.
I have deployed the same wars in jboss-eap-6.2 and that worked for me.
> Share the same jsessionid in different context root
> ----------------------------------------------------
>
> Key: WFLY-3845
> URL: https://issues.jboss.org/browse/WFLY-3845
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Wildfly 8.1.0.Final
> Reporter: Sandeep Samdaria
> Assignee: Stuart Douglas
>
> I have two applications which need a Single Sign On. User once logged into an application should not need login again to another application.
> To achieve that I was storing the session id in the cookie. The other application used to retrieve the session and verify the user.
> Now, the problem that I am facing, after upgrading to wildfly, is that the each application is producing different jsessionid. I have also tried the workaround mentioned in https://issues.jboss.org/browse/WFLY-3617, but in vain.
> I have deployed the same wars in jboss-eap-6.2 and that worked for me.
> I have copied the two war over here https://www.dropbox.com/sh/cq5p373wasn5svj/AACyZaBMBCGaNMaBU8zbW82Za?dl=0
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years