[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Ales Justin updated WELD-855: ----------------------------- Comment: was deleted (was: So, the issue is you actually expect NonexistentConversationException, but you end up with "java.lang.IllegalStateException: Unable to load current conversations from the associated request, something went badly wrong when associate() was called"? ) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on WELD-855: ------------------------------------ If I push an invalid cid, a NonexistentConversationException is thrown as expected. Seam Catch has been configured as a JSF Excpetion Hanlder, to handle exceptions. As it tries to invoke the method that handles this exception, an IllegalStateException is thrown while trying to restore the conversation. This IllegalStateException should not be thrown. In this case there is no Conversation to restore, which is why the NonexistentConversationException was thrown in the first place. Please le me know if I can add any further explanation as to the expected behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on WELD-855: ------------------------------------ I can confirm that WeldListener.requestInitialized is invoked when I request a URL with an non-existent cid. I don't see a beginRequest method in Weld Listener. Note: I am using the latest Weld 1.1 SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on WELD-855: ------------------------------------ Looking at this with levels instead of breakpoints one can see the method is hit only once. WeldListener.requestInitialized begins with the trace message: log.trace(REQUEST_INITIALIZED, event.getServletRequest()); Steps: 1) Start the application 2) Visit a protected URL 3) Log in to the application 4) Ensure the protected page renders correctly 5) append "?cid=5", or some other bogus conversation id to the URL, and click enter. The following log output is produced, where one can see the WELD-000708 message only one time, before the stack trace: --------------------- FINEST: WELD-000708 Initializing request org.apache.catalina.connector.RequestFacade@111a848b INFO: Catch integration enabled WARN: Using JSF provided instance, unable to find a BeanManaged instance for class javax.faces.validator.BeanValidator WARNING: StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception java.lang.RuntimeException: Exception invoking method [conversationExpired] on object [ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler@352d8328], using arguments [org.jboss.seam.exception.control.CaughtException@3efdd25e,com.sun.faces.context.FacesContextImpl(a)9fe39a1] at org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:547) at org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:458) at org.jboss.seam.solder.reflection.annotated.InjectableMethod.invoke(InjectableMethod.java:189) at org.jboss.seam.exception.control.HandlerMethodImpl.notify(HandlerMethodImpl.java:189) at org.jboss.seam.exception.control.ExceptionHandlerDispatch.executeHandlers(ExceptionHandlerDispatch.java:130) at org.jboss.seam.exception.control.org$jboss$weld$bean-WEB-INF$lib$seam-catch-impl-3$0$0-SNAPSHOT-ManagedBean-class_org$jboss$seam$exception$control$ExceptionHandlerDispatch_$$_WeldClientProxy.executeHandlers(org$jboss$weld$bean-WEB-INF$lib$seam-catch-impl-3$0$0-SNAPSHOT-ManagedBean-class_org$jboss$seam$exception$control$ExceptionHandlerDispatch_$$_WeldClientProxy.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188) at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59) at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222) at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632) at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619) at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613) at org.jboss.seam.faces.exception.CatchExceptionHandler.handle(CatchExceptionHandler.java:83) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.IllegalStateException: Unable to load current conversations from the associated request, something went badly wrong when associate() was called at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:413) at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:91) at com.sun.faces.application.view.MultiViewHandler.getRedirectURL(MultiViewHandler.java:381) at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:204) at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:204) at org.jboss.weld.jsf.ConversationAwareViewHandler.getRedirectURL(ConversationAwareViewHandler.java:134) at com.sun.faces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:166) at org.jboss.seam.faces.event.SeamPreNavigationHandler.handleNavigation(SeamPreNavigationHandler.java:77) at ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler.conversationExpired(ExceptionCatchHandler.java:29) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125) at ca.triumf.mis.qms.workrequest.jsf.exception.org$jboss$weld$bean-WorkRequest-ManagedBean-class_ca$triumf$mis$qms$workrequest$jsf$exception$ExceptionCatchHandler_$$_WeldClientProxy.conversationExpired(org$jboss$weld$bean-WorkRequest-ManagedBean-class_ca$triumf$mis$qms$workrequest$jsf$exception$ExceptionCatchHandler_$$_WeldClientProxy.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:535) ... 52 more FINEST: WELD-000709 Destroying request org.apache.catalina.connector.RequestFacade@111a848b --------------- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on WELD-855: -------------------------------- Ok, that last comment is the uesful one. Can you switch out the stack traces etc. to show it without any authz in the way? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Ryan Slominski commented on WELD-855: ------------------------------------- I'm getting this exception and I'm not using Seam / Faces Catch. I simply have a custom exception handler to handle NonexistentConversationExceptions (i.e. the user bookmarks a page with a cid in the URL and tries to access it later). I'd like to simply redirect the user to the same page (which would start a new conversation). If I invoke the NavigationHandler (directly or indirectly via ViewHandler.getActionURL) I get the IllegalStateException. This seems like a pretty important bug since there is no clean way to redirect the user when encountering this common case (User tries to access a nonexistent conversation). One workaround is to perform a redirect without invoking the NavigationHandler (ExternalContext.redirect). This doesn't seem to work with Ajax requests unfortunately (I'm seeing two sets of <redirect> tags for some reason...). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Ryan Slominski edited comment on WELD-855 at 7/19/11 11:57 AM: --------------------------------------------------------------- I'm getting this exception and I'm not using Seam / Faces Catch. I simply have a custom exception handler to handle NonexistentConversationExceptions (i.e. the user bookmarks a page with a cid in the URL and tries to access it later). I'd like to simply redirect the user to the same page (which would start a new conversation). If I invoke the NavigationHandler (directly or indirectly via ViewHandler.getActionURL) I get the IllegalStateException. This seems like a pretty important bug since there is no clean way to redirect the user when encountering this common case (User tries to access a nonexistent conversation). One workaround is to perform a redirect without invoking the NavigationHandler (ExternalContext.redirect). was (Author: slominskir): I'm getting this exception and I'm not using Seam / Faces Catch. I simply have a custom exception handler to handle NonexistentConversationExceptions (i.e. the user bookmarks a page with a cid in the URL and tries to access it later). I'd like to simply redirect the user to the same page (which would start a new conversation). If I invoke the NavigationHandler (directly or indirectly via ViewHandler.getActionURL) I get the IllegalStateException. This seems like a pretty important bug since there is no clean way to redirect the user when encountering this common case (User tries to access a nonexistent conversation). One workaround is to perform a redirect without invoking the NavigationHandler (ExternalContext.redirect). This doesn't seem to work with Ajax requests unfortunately (I'm seeing two sets of <redirect> tags for some reason...). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Darren Kramer commented on WELD-855: ------------------------------------ I am having the same problem with Tomcat 7. I am able to catch the NonexistentConversationException. However, I then get a followup IllegalStateException. Tracing through the code, I see that what is happening is that in WeldPhaseListener inside of activateConversations() it is throwing the NonexistentConversationException. But because it is throwing it, it never calls "conversationContext.activate(cid);" which would have created a Conversation if one didn't exist. So in the later phases we still don't have a valid Conversation and that is when the IllegalStateException comes from. I was able to work around this in my ExceptionHandler by adding: ConversationContext conversationContext = Container.instance().deploymentManager().instance().select(Context.class).select(HttpConversationContext.class).get(); conversationContext.activate(null); But that is obviously a hack that I wouldn't want to normally do. According to the javadoc for NonexistentConversationException, the container is supposed to throw this exception when the Conversation cannot be restored but should also create a new conversation. It doesn't appear that is happening. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Ove Ranheim commented on WELD-855: ---------------------------------- I experience the same too and thanks for the workaround/hack in conjunction with Seam Catch it "solves" the problem, after the call to conversationContext.active(null) and event.handled(). In my app I get the NonexistentConversationException when: 1) SearchForm with a commandButton (excepted behavior is to have a non conversation scope when clicked) 2) RegisterForm part of a long-running conversation 3) If RegisterForm is not completed and the conversation ended, said user click on the search-button in SearchForm; the NonexistentConversationException is being thrown. With the hack described above, the cid from RegisterForm is still appended to the URL within the action to Search. But, it does work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Darren Kramer commented on WELD-855: ------------------------------------ The Container class is: org.jboss.weld.Container. The fact that I am referencing the Weld CDI implementation instead of using a solution that would work for any CDI implementation (if any other implementations also experience this bug) is why I label this as a hack. I assume with BeanManager you are referring to BeanManager.getContext()? That very well may work. There very well may be other ways to solve this problem. This was just the first way I found to work around it and frankly I stopped looking after that. Just implement a normal ExceptionHandler, and whenever you detect a NonexistentConversationException add those two lines plus any other custom code you desire and that should resolve the problem until a permanent fix is released (hopefully). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Ove Ranheim commented on WELD-855: ---------------------------------- How about: {noformat} public void conversationEndedExceptionHandler(@Handles CaughtException<NonexistentConversationException> event, Logger log) { log.infof(x"Conversation ended: %s", event.getException().getMessage()); ConversationContext conversationContext = Container.instance().deploymentManager().instance().select(Context.class).select(HttpConversationContext.class).get(); conversationContext.activate(null); event.handled(); } {noformat} If you need to redirect the user, do something like (requires FacesContext to be injected on your bean): {noformat} private void handleErrorRediredct(FacesContext facesContext) { facesContext.getApplication().getNavigationHandler().handleNavigation(facesContext, null, "/error.jsf"); } {noformat} The evt.markHandled() will cause other exception "catchers" with a lower precedence to be called. Try to use only evt.handled() unless it violates your use case and concern. If you stick to simple evt.handled() your faces-config.xml will still apply and your app short work normally. I really hope that the Weld team could look into this and fix it once and for all. In fact, it makes the Weld + Solder (soon DeltaSpike) unusable to web developers. IMHO, it's a blocker bug for apps doing more than "Hello World!". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Ove Ranheim edited comment on WELD-855 at 12/16/11 4:18 PM: ------------------------------------------------------------ How about: {noformat} public void conversationEndedExceptionHandler(@Handles CaughtException<NonexistentConversationException> event, Logger log) { log.infof("Conversation ended: %s", event.getException().getMessage()); ConversationContext conversationContext = Container.instance().deploymentManager().instance().select(Context.class).select(HttpConversationContext.class).get(); conversationContext.activate(null); event.handled(); } {noformat} If you need to redirect the user, do something like (requires FacesContext to be injected on your bean): {noformat} private void handleErrorRediredct(FacesContext facesContext) { facesContext.getApplication().getNavigationHandler().handleNavigation(facesContext, null, "/error.jsf"); } {noformat} The evt.markHandled() will cause other exception "catchers" with a lower precedence to be called. Try to use only evt.handled() unless it violates your use case and concern. If you stick to simply: evt.handled() your faces-config.xml will still apply and your app should work normally. I really hope that the Weld team could look into this and fix it once and for all. In fact, it makes the Weld + Solder (soon DeltaSpike) unusable to web developers. IMHO, it's a blocker bug for apps doing more than "Hello World!". The above "fix" does the work though. was (Author: oranheim): How about: {noformat} public void conversationEndedExceptionHandler(@Handles CaughtException<NonexistentConversationException> event, Logger log) { log.infof("Conversation ended: %s", event.getException().getMessage()); ConversationContext conversationContext = Container.instance().deploymentManager().instance().select(Context.class).select(HttpConversationContext.class).get(); conversationContext.activate(null); event.handled(); } {noformat} If you need to redirect the user, do something like (requires FacesContext to be injected on your bean): {noformat} private void handleErrorRediredct(FacesContext facesContext) { facesContext.getApplication().getNavigationHandler().handleNavigation(facesContext, null, "/error.jsf"); } {noformat} The evt.markHandled() will cause other exception "catchers" with a lower precedence to be called. Try to use only evt.handled() unless it violates your use case and concern. If you stick to simple evt.handled() your faces-config.xml will still apply and your app short work normally. I really hope that the Weld team could look into this and fix it once and for all. In fact, it makes the Weld + Solder (soon DeltaSpike) unusable to web developers. IMHO, it's a blocker bug for apps doing more than "Hello World!". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Ales Justin commented on WELD-855: ---------------------------------- @Ove: I guess your "fix" requires Catch to be used? But could you - as you know the details of this issue - provide a Weld patch (or actually a github pull-request)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on WELD-855: -------------------------------- Ales, we just need to fix the underlying issue, the Catch thing is just showing up this bug. I think there is just some bug in the conversation handling logic. Maybe Jason or Brian can help you create a test without catch in the picture? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira