jsf session timeout loop - jsf

I've a problem with JSF session handling:
At first i got everytime a viewExpiredException:
javax.faces.application.ViewExpiredException: viewId:/anyForm.jsf - View /anyForm.jsf could not be restored.
So I added the following code to my web.xml file:
<error-page>
<exception-type>javax.faces.application.ViewExpiredException</exception-type>
<location>/index.jsf?reason=expired</location>
</error-page>
and the following in my index.jsf file (which also got some forms and inputs):
<h:outputText value="#{messages.session_expired}"
rendered="#{param.reason == 'expired'}" />
whenever I get a timeout now, I am redirected to the index.jsf and the text is shown, but if I enter a value in an input and press the submit button of the form, I still get a redirect to my index.jsf. So, I am stuck in a loop. I also tried things like:
<context-param>
<param-name>com.sun.faces.enableRestoreView11Compatibility</param-name>
<param-value>true</param-value>
</context-param>
due to the fact that I read index.jsf then automatically create a new session. However, this didn't help me at all.
I also get this exception if I got a (loop) timeout and change a value of a input and submit the form (I am using primefaces "spinner" input):
javax.servlet.ServletException: Index: 1, Size: 1
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
java.util.ArrayList.RangeCheck(ArrayList.java:547)
java.util.ArrayList.get(ArrayList.java:322)
javax.faces.component.AttachedObjectListHolder.restoreState(AttachedObjectListHolder.java:165)
javax.faces.component.UIInput.restoreState(UIInput.java:1411)
com.sun.faces.application.view.StateManagementStrategyImpl$2.visit(StateManagementStrategyImpl.java:276)
com.sun.faces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:151)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1589)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1600)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1600)
javax.faces.component.UIForm.visitTree(UIForm.java:344)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1600)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1600)
com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:263)
com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:188)
com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:452)
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:148)
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)

Related

Add client behavior dynamically with var components

I'm trying to listen event from components contained in DynaForm of primefaces-extensions, so developer can do dynamically do some custom stuff. At the end I would like to be able to do this:
<pe:dynaForm id="dynaForm" value="#{dynaFormController.model}" var="data" controlKey="#{data.name}">
<pe:dynaFormControl type="input" for="txt">
<p:inputText id="txt" value="#{data.value}" required="#{data.required}" />
</pe:dynaFormControl>
<my:ajax event="keyup" listener="#{controller.authorSelected}" key="author"/>
</pe:dynaForm>
What I want to do:
Whenever the key defined in my:ajax match the controlKey of a pe:dynaFormControl, I want to attach the my:ajax client behavior to the p:inputText.
Problems encountered:
At first, I did all of this in DynaFormRenderer#encodeBody, quite convenient since var is put in the EL context. But I ended up having this exception (similar to this https://github.com/javaserverfaces/mojarra/issues/4365):
java.lang.NullPointerException
at javax.faces.component.UIComponentBase.restoreBehaviors(UIComponentBase.java:2228)
at javax.faces.component.UIComponentBase.restoreBehaviorsState(UIComponentBase.java:2203)
at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1623)
at javax.faces.component.UIOutput.restoreState(UIOutput.java:286)
at javax.faces.component.UIInput.restoreState(UIInput.java:1422)
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy$2.visit(FaceletPartialStateManagementStrategy.java:379)
at com.sun.faces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:151)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1689)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIForm.visitTree(UIForm.java:371)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:366)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:591)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:151)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:199)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
Then I tried to do just like o:moveComponent from Omnifaces using PreRenderViewEvent, but var is not available at this moment, in fact, calling DynaForm#getValue() always return null.
Do you have any suggestions how properly attach client behavior dynamically when var comes in the picture?
More infos: Mojarra 2.2.15 & Tomcat 8

Alternative to f:verbatim in JSF 2.1

Alternative to f:verbatim in JSF 2.1 for rendering purpose is needed. In my application I am using ui:fragment rendered instead of f:verbatim but it is not working in jsf 2.1.
Here i am providing my code
<f:verbatim rendered="#{not empty focusField}">
<script type="text/javascript">
$(document).ready(function(){
// If the class is not set, do so now
$("#menuContainer > ul:first:not(.sf-menu)").addClass("sf-menu");
$("ul.sf-menu").supersubs({
minWidth: 12, // minimum width of sub-menus in em units
maxWidth: 27, // maximum width of sub-menus in em units
extraWidth: 1 // extra width can ensure lines don't sometimes turn over
// due to slight rounding differences and font-family
}).superfish({
delay: 300
});
});
</script>
</f:verbatim>
<ui:component>
<ui:fragment rendered="#{not empty focusField}">
<script type="text/javascript">
$(document).ready(function(){
// If the class is not set, do so now
$("#menuContainer > ul:first:not(.sf-menu)").addClass("sf-menu");
$("ul.sf-menu").supersubs({
minWidth: 12, // minimum width of sub-menus in em units
maxWidth: 27, // maximum width of sub-menus in em units
extraWidth: 1 // extra width can ensure lines don't sometimes turn over
// due to slight rounding differences and font-family
}).superfish({
delay: 300
});
});
</script> </ui:fragment>
</ui:component>
I am getting this error
Root cause of ServletException.
org.springframework.webflow.execution.FlowExecutionException: Exception thrown in state 'demo' of flow 'demo'
at org.springframework.webflow.engine.impl.FlowExecutionImpl.wrap(FlowExecutionImpl.java:571)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:262)
at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:169)
at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused By: javax.faces.FacesException: Component ID demo has already been found in the view.
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:142)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at org.springframework.faces.webflow.FlowLifecycle.render(FlowLifecycle.java:80)
at org.springframework.faces.webflow.JsfView.render(JsfView.java:89)
at org.springframework.webflow.engine.ViewState.render(ViewState.java:296)
at org.springframework.webflow.engine.ViewState.refresh(ViewState.java:243)
at org.springframework.webflow.engine.ViewState.resume(ViewState.java:221)
at org.springframework.webflow.engine.Flow.resume(Flow.java:545)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:258)
at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:169)
at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
Caused By: java.lang.IllegalStateException: Component ID demo has already been found in the view.
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:910)
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:894)
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:894)

Faces messages are not cleared on subsequent requests

Case is as follows:
you have a bean method which parses a file, and if parsing fail, error message is added, and if parsing successful, success message is added.
But when you make consecutive operations: fail > success , i expect that the fail message will disappear and the success message appears, but what happens is that fail message is still there, and success message is added to it.
Clearing the MessageList before adding the message is not a solution, because list is already cleared, if you try to print the message list size before adding the message in both cases it will be 0.
So what is the solution to remove fail message in case of success and vice versa?
Bean:
#Component("mybean")
#Scope("view")
public class MyBean {
try {
myservice.parseFile(file);
} catch (Exception e) {
FacesMessage msg = new FacesMessage();
msg.setSeverity(FacesMessage.SEVERITY_FATAL);
msg.setSummary("Invalid file.");
facesContext.addMessage(null, msg);
return;
}
FacesMessage msg = new FacesMessage();
msg.setSeverity(FacesMessage.SEVERITY_INFO);
msg.setSummary("Success");
facesContext.addMessage(null, msg);
}
View:
<h:form>
<ace:fileEntry id="fileEntryComp"
label="File Entry"
relativePath="uploaded"
fileEntryListener="#{mybean.listener}" />
<h:commandButton value="Upload File" />
<h:messages styleClass="myclass" infoStyle="Color:blue;" errorStyle="Color:red;" fatalStyle="margin-right: 85%; Color:red;" globalOnly="true"/>
<h:messages for="fileEntryComp" style="display:none;"/> <!-- to hide the faces development message-->
</h:form>
UPDATE:
i tried even the workaround here:
Is is possible to delete Component HTML Content with JSF
to clear the messages div before adding new messages, but no new, i don't know where he gets the old message from.
UPDATE2:
i even tried the two workaround mentioned here:
http://www.icefaces.org/JForum/posts/list/19753.page#71521
1- Adding context param:
<context-param>
<param-name>org.icefaces.messagePersistence</param-name>
<param-value>false</param-value>
</context-param>
doesn't work too.
2- Clearing saved global messages collection:
i tried this solution:
List<FacesMessage> globals = (List<FacesMessage>) facesContext.getViewRoot().getAttributes().get("org.icefaces.event.saved_global_faces_messages");
if (globals != null) {
globals.clear();
}
but i always get the following exception:
Caused by: java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableCollection.clear(Collections.java:1037)
at com.xeno.phoneSuite.beans.DepartmentBean.listener(DepartmentBean.java:176)
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.apache.el.parser.AstValue.invoke(AstValue.java:262)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at org.icefaces.component.fileentry.FileEntry.broadcast(FileEntry.java:311)
... 92 more
finally, i tried the solution of the context param on the latest version ICEfaces 2.1 Beta 2 and it works fine:
<context-param>
<param-name>org.icefaces.messagePersistence</param-name>
<param-value>false</param-value>
</context-param>
http://wiki.icefaces.org/display/ICE/ICEfaces+2.1.0+Beta+2+Release+Notes#ICEfaces2.1.0Beta2ReleaseNotes-downloads
hope that will helps.
I am in Icefaces 3.3 and had a similar problem. I solved this using the following code (Oh BTW I also see that #BalusC has already pointed out such a solution in his comments):
Iterator<FacesMessage> msgIterator = FacesContext.getCurrentInstance().getMessages();
while (msgIterator.hasNext())
{
FacesMessage facesMessage = msgIterator.next();
msgIterator.remove();
}
Putting above piece of code before pushing a new message like this one, should clear your old message and replace it with the new message My Message:
FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO, "My Message", null));
I struggled a lot and finally the fix was very simple whether it is prime faces or old faces, just add redisplay = false.
Below is the snippet of the code.
<p:messages id="globalMessages" global-only="true" redisplay="false">
<p:autoUpdate/>
</p:messages>

After confirmation, navigate to first tab of wizard

Pretty much, everything is said in title of topic.What I need to achieve is that when I am in last (confirm) tab of wizard and click on my button, after everything is done, I want to back to first tab of wizard. Of course, everything in wizard should be reset after that.
Well, it isn't help. Currently I am totally confused. On click of button I get this exception, but not in server log, only in browser I get:
An Error Occurred:
java.lang.NullPointerException
java.lang.NullPointerException
at org.primefaces.component.datatable.DataHelper.decodeFilters(DataHelper.java:167)
at org.primefaces.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:51)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:790)
at javax.faces.component.UIData.processDecodes(UIData.java:980)
at org.primefaces.component.datatable.DataTable.processDecodes(DataTable.java:542)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042)
at org.primefaces.component.panel.Panel.processDecodes(Panel.java:282)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042)
at org.primefaces.component.wizard.Wizard.processDecodes(Wizard.java:210)
at javax.faces.component.UIForm.processDecodes(UIForm.java:216)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042)
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:941)
at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Button looks like this:
<p:commandButton ajax="false" value="Save service" action="#{kuBean.saveService}"
update="growl"/>
Interesting...
Assuming that your bean is #ViewScoped then a simple page redirect to the url of your wizard page should reinstantiate your wizards managed bean. If that doesn't work you can append the GET property [url]?faces-redirect=true to the URL.
This won't work if your managed bean is #SessionScoped however as the data and state information from the previous wizard confirmation will likely still be there. The best solution would be to switch to ViewScoped and if that is not possible then write a reset method of the managed bean that can clear the state and data of the managed bean.
try using the flowListener of the p:wizard
<p:wizard flowListener="#{userWizard.handleFlow}">
...
</p:wizard>
in your bean:
public String handleFlow(FlowEvent event) {
String currentStepId = event.getCurrentStep();
String stepToGo = event.getNextStep();
//if(skip)
//return "confirm";
//else
//return event.getNextStep();
... portion where you are to return to the first tab
return "id_value_of_first_tab";
}

Weld 1.0.1-Final: Conversation Scope bean keeps recreated even after beginning conversation?

Im currently using :
Apache tomcat 7
JBoss Weld servlet 1.0.1-Final
empty beans.xml
<listener-class>org.jboss.weld.environment.servlet.Listener</listener-class> in the web.xml
I'm currently testing a simple counter #ConversationScoped bean, and the intention is, after beginning the conversation scope, to keep incrementing the counter whenever the button is clicked ..
But it seems that after submit, the bean will always be recreated, even after i've begin the conversation in the 1st place.
Here's my simple bean :
package user.ui;
import java.io.Serializable;
import javax.annotation.PostConstruct;
import javax.enterprise.context.Conversation;
import javax.enterprise.context.ConversationScoped;
import javax.inject.Inject;
import javax.inject.Named;
#Named
#ConversationScoped
public class CounterBean implements Serializable {
#Inject
private Conversation conversation;
#PostConstruct
public void init() {
System.out.println("beginning conversation : " + this.conversation);
this.conversation.begin();
}
private int counter;
public int getCounter() {
return counter;
}
public void setCounter(int counter) {
this.counter = counter;
}
public void increment() {
this.counter++;
}
}
Here's my simple jsf view :
<ui:composition template="/template/masterlayout.xhtml">
<ui:define name="windowTitle">Test Conversation Scope</ui:define>
<ui:define name="heading">Test Conversation Scope</ui:define>
<ui:define name="content">
<h:form>
<p:messages id="messages" globalOnly="true" />
<p:panel header="Test Conversation Scope">
<h:outputText value="counter : " /> #{counterBean.counter}
</p:panel>
<h:commandButton value="Submit Data to Server" action="#{counterBean.increment}" />
</h:form>
</ui:define>
</ui:composition>
Here's the log file for the 1st access :
INFO: Server startup in 12055 ms
beginning conversation : ID: 1, transient: true, timeout: 600000ms
And after the view is displayed, i clicked on the button, and there goes the exception throwing with this log in catalina.out :
beginning conversation : ID: 2, transient: true, timeout: 600000ms
unhandled exception : org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type #ConversationScoped
cause exception : org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type #ConversationScoped, cause exception is BE : false
Here's the exception trace from tomcat log :
Apr 4, 2011 3:56:27 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/primebert] threw exception [WELD-001303 No active contexts for scope type #ConversationScoped] with root cause
org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type #ConversationScoped
at org.jboss.weld.conversation.ConversationImpl.checkConversationActive(ConversationImpl.java:79)
at org.jboss.weld.conversation.ConversationImpl.isTransient(ConversationImpl.java:234)
at org.jboss.weld.conversation.ConversationImpl.toString(ConversationImpl.java:199)
at java.text.MessageFormat.subformat(MessageFormat.java:1246)
at java.text.MessageFormat.format(MessageFormat.java:836)
at java.text.Format.format(Format.java:140)
at java.text.MessageFormat.format(MessageFormat.java:812)
at ch.qos.cal10n.MessageConveyor.getMessage(MessageConveyor.java:89)
at org.jboss.weld.logging.WeldMessageConveyor.getMessage(WeldMessageConveyor.java:78)
at org.slf4j.cal10n.LocLogger.debug(LocLogger.java:95)
at org.jboss.weld.conversation.ConversationImpl.switchTo(ConversationImpl.java:190)
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:304)
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:298)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:113)
at org.jboss.weld.util.CleanableMethodHandler.invoke(CleanableMethodHandler.java:43)
at org.jboss.weld.conversation.ConversationImpl_$$_javassist_2.switchTo(ConversationImpl_$$_javassist_2.java)
at org.jboss.weld.conversation.AbstractConversationManager.beginOrRestoreConversation(AbstractConversationManager.java:137)
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:304)
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:298)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:113)
at org.jboss.weld.util.CleanableMethodHandler.invoke(CleanableMethodHandler.java:43)
at org.jboss.weld.conversation.ServletConversationManager_$$_javassist_0.beginOrRestoreConversation(ServletConversationManager_$$_javassist_0.java)
at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener.java:171)
at org.jboss.weld.jsf.WeldPhaseListener.beforeRestoreView(WeldPhaseListener.java:118)
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:87)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:383)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:288)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Any ideas what went wrong ?
Thank you !
To keep track of the long-running conversation Weld inserts the cid parameter in the action method of the HTML form.
In your case you start the long-running conversation in the PostConstruct method of the counterBean. But the counterBean gets referenced first inside the h:form, so by the time counterBean gets initialized the h:form's header was already rendered. You need to start the conversation earlier.
I'm not sure what's the best way to do that. Probably like that:
<f:metadata>
<f:event type="preRenderView" listener="#{someBean.init}"/>
</f:metadata>
You could start the conversation on GET request only:
public void init() {
if (!FacesContext.getCurrentInstance().isPostback()) {
conversation.begin();
}
}
JSF 2.2 has a <f:viewAction> tag (analogous to Seam page actions), that could be used to accomplish the same thing.
Alternatively you can just place this EL expression above the form:
#{javax.enterprise.context.conversation.begin()}
But then you have to be careful not to re-render this expression again.
As a side note, a conversation is often started on some JSF action, such as a button click. One needs to keep in mind, that for a proper conversation propagation forms need to be re-rendered.
From a CDI point of view, your code should work (it actually works on a JBoss AS 6). What seems to happen is that the conversation isn't propagated between two requests, but that should be implicit when using JSF form submits. I assume your setup is wrong and Tomcat isn't configured as it should be.
As a first step, try to propagate the conversation id manually, as described here.
We've seen the same so work around it we are performing a redirect back to the page as soon as we start a conversation. We know which parts of our app need conversations based on form id prefix, so can do this in an early phase listener. After Restore View works well. I'm having trouble performing redirects from Before Restore View which would be more ideal.
I've ended up using HttpServletRequest from FacesContext.getExternalContext().getRequest() which can give the full URL to redirect to. I do break it down in code and recombine it - the structure of our code and a reusable class to contain the concept of a form and parameters. The sendRedirect with exception handling removed is
ExternalContext external = faces.getExternalContext();
String baseUrl = external.getRequestContextPath() + m_formId;
String target = external.encodeRedirectURL(baseUrl, m_requestParameters);
external.redirect(target);

Resources