Re: Random JSF error: no saved view state could be found
Hmm, can be interesting if you have enough time to try to reproduce it in a shareable (on github?) project. I'm sure it is something stupid we don't see ATM. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/1 Zmirc zmircmir...@gmail.com Hi! Yes, I run Majorra on Tomee 1.6.0 from 13.09.20. I will switch today to 13.10.01 to see if that bug with @Schedule leak disappeared. I understand your point of view and I agree. I have no idea which one has the bug, just that I don't get it on Majorra. (I've just deleted myfaces jars from Tomee and added Majorra 2.1.26 - nothing special) What settings should I give you? I didn't modify anything in Tomee, excepting perm gen size, heap (on production) and a few more things in setenv. Here's the setenv on my windows. (It's the same on linux also, just as .sh) set JAVA_OPTS=%JAVA_OPTS% -XX:MaxPermSize=512m set JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.session.** StandardSession.ACTIVITY_**CHECK=true set JAVA_OPTS=%JAVA_OPTS% -Dopenejb.session-context=http set JAVA_OPTS=%JAVA_OPTS% -Dfacebook4j.loggerFactory=** facebook4j.internal.logging.**NullLoggerFactory So...the error happens randomly (just sometimes to some users) for all pages that modify information and are backed by a @ViewScoped bean: The following logs are from Tomee 1.6.0 13.09.20. It happens the same on 1.5.2. I moved on 1.6.0 hoping to get rid of it. javax.servlet.**ServletException: /dashboard/edit-profile.**xhtmlNo saved view state could be found for the view identifier: /dashboard/edit-profile.xhtml at javax.faces.webapp.**FacesServlet.service(**FacesServlet.java:213) ~[myfaces-api-2.1.12.jar:2.1.**12] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**305) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at org.primefaces.webapp.filter.**FileUploadFilter.doFilter(**FileUploadFilter.java:77) ~[primefaces-3.5.jar:na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at org.ocpsoft.rewrite.servlet.**RewriteFilter.doFilter(**RewriteFilter.java:199) ~[rewrite-servlet-2.0.7.Final.**jar:2.0.7.Final] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at com.pingushare.boundary.**filter.ActivateAccountFilter.**doFilter(* *ActivateAccountFilter.java:38) ~[ActivateAccountFilter.class:**na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at com.pingushare.boundary.**filter.SecurityFilter.** doFilter(SecurityFilter.java:**36) ~[SecurityFilter.class:na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at com.pingushare.boundary.**filter.**ForceFreshPageAndWWWFilter.** doFilter(**ForceFreshPageAndWWWFilter.**java:41) ~[ForceFreshPageAndWWWFilter.**class:na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**StandardWrapperValve.invoke(**StandardWrapperValve.java:222) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**StandardContextValve.invoke(**StandardContextValve.java:123) ~[catalina.jar:7.0.42] at org.apache.tomee.catalina.**OpenEJBValve.invoke(**OpenEJBValve.java:45) ~[tomee-catalina-1.6.0-**SNAPSHOT.jar:1.6.0-SNAPSHOT] at org.apache.catalina.**authenticator.**AuthenticatorBase.invoke(**AuthenticatorBase.java:502) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**StandardHostValve.invoke(**StandardHostValve.java:171) ~[catalina.jar:7.0.42] at org.apache.catalina.valves.**ErrorReportValve.invoke(**ErrorReportValve.java:99) ~[catalina.jar:7.0.42] at
Re: Random JSF error: no saved view state could be found
Yes, absolutely. These kind of issues are really hard to reproduce, even more to debug. I'm still thinking it should be something else, but anyway if we can find what's going on and if the issue is related to myfaces it will be fixed in no time. On Oct 1, 2013 10:00 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hmm, can be interesting if you have enough time to try to reproduce it in a shareable (on github?) project. I'm sure it is something stupid we don't see ATM. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/1 Zmirc zmircmir...@gmail.com Hi! Yes, I run Majorra on Tomee 1.6.0 from 13.09.20. I will switch today to 13.10.01 to see if that bug with @Schedule leak disappeared. I understand your point of view and I agree. I have no idea which one has the bug, just that I don't get it on Majorra. (I've just deleted myfaces jars from Tomee and added Majorra 2.1.26 - nothing special) What settings should I give you? I didn't modify anything in Tomee, excepting perm gen size, heap (on production) and a few more things in setenv. Here's the setenv on my windows. (It's the same on linux also, just as .sh) set JAVA_OPTS=%JAVA_OPTS% -XX:MaxPermSize=512m set JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.session.** StandardSession.ACTIVITY_**CHECK=true set JAVA_OPTS=%JAVA_OPTS% -Dopenejb.session-context=http set JAVA_OPTS=%JAVA_OPTS% -Dfacebook4j.loggerFactory=** facebook4j.internal.logging.**NullLoggerFactory So...the error happens randomly (just sometimes to some users) for all pages that modify information and are backed by a @ViewScoped bean: The following logs are from Tomee 1.6.0 13.09.20. It happens the same on 1.5.2. I moved on 1.6.0 hoping to get rid of it. javax.servlet.**ServletException: /dashboard/edit-profile.**xhtmlNo saved view state could be found for the view identifier: /dashboard/edit-profile.xhtml at javax.faces.webapp.**FacesServlet.service(**FacesServlet.java:213) ~[myfaces-api-2.1.12.jar:2.1.**12] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**305) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at org.primefaces.webapp.filter.**FileUploadFilter.doFilter(**FileUploadFilter.java:77) ~[primefaces-3.5.jar:na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at org.ocpsoft.rewrite.servlet.**RewriteFilter.doFilter(**RewriteFilter.java:199) ~[rewrite-servlet-2.0.7.Final.**jar:2.0.7.Final] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at com.pingushare.boundary.**filter.ActivateAccountFilter.**doFilter(* *ActivateAccountFilter.java:38) ~[ActivateAccountFilter.class:**na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at com.pingushare.boundary.**filter.SecurityFilter.** doFilter(SecurityFilter.java:**36) ~[SecurityFilter.class:na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at com.pingushare.boundary.**filter.**ForceFreshPageAndWWWFilter.** doFilter(**ForceFreshPageAndWWWFilter.**java:41) ~[ForceFreshPageAndWWWFilter.**class:na] at org.apache.catalina.core.**ApplicationFilterChain.** internalDoFilter(**ApplicationFilterChain.java:**243) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** ApplicationFilterChain.java:**210) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**StandardWrapperValve.invoke(**StandardWrapperValve.java:222) ~[catalina.jar:7.0.42] at org.apache.catalina.core.**StandardContextValve.invoke(**StandardContextValve.java:123) ~[catalina.jar:7.0.42] at org.apache.tomee.catalina.**OpenEJBValve.invoke(**OpenEJBValve.java:45) ~[tomee-catalina-1.6.0-**SNAPSHOT.jar:1.6.0-SNAPSHOT] at
Re: Random JSF error: no saved view state could be found
response inline/below... On Tue, Oct 1, 2013 at 1:13 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: About it works with mojarra so that's mf it is a big shortcut. It can be a bug in mojarra which make it working too (im not saying it, just you dont know and you cant conclude since you were not able to give us any info on this issue we can use to work on it) I agree with this. when i migrated from mojarra 2.1.7 to myfaces 2.1.8 (in late year 2012), I found out that mojarra allowed me to get away with many many things, maybe since I was junior-JSF-developer, and it gave me feeling that mojarra works well and is recommended for junior-JSF-developers because it allows your app to 'just work' regardless if your code is correct or not. definitely not calling you a junior developer, but when i migrated from mojarra to myfaces, my experience was...i had to 'fix' a bunch of my code, because my (junior-JSF-developer) code was not working with myfaces. will respond more, as i saw some things in your latest post... (my comments are directed at OP)
Re: Random JSF error: no saved view state could be found
responses inline, below.
On Tue, Oct 1, 2013 at 3:45 AM, Zmirc zmircmir...@gmail.com wrote:
set JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.session.**
StandardSession.ACTIVITY_**CHECK=true
set JAVA_OPTS=%JAVA_OPTS% -Dopenejb.session-context=http
these two are definitely interesting, even though you stated, earlier, that
you are not really doing much/any session-management logic/checks. i don't
know the purpose of standardsession.activity_check and
openejb.session-context=http, but 'session' says a lot (to me).
set JAVA_OPTS=%JAVA_OPTS% -Dfacebook4j.loggerFactory=**
facebook4j.internal.logging.**NullLoggerFactory
facebook4j? wow, never heard of that. interesting.
So...the error happens randomly (just sometimes to some users) for all
pages that modify information and are backed by a @ViewScoped bean:
I looked at your bean, and it is quite interesting that this (JSF)
'managedbean',
@ManagedBean(name = addItem)
@ViewScoped
public class AddItemB implements Serializable {
uses CDI to @Inject the following:
@Inject
UserDataB udB;
@Inject
ItemC itemC;
@Inject
ImageC imageC;
@Inject
UserC userC;
I don't know if MyFaces' implementation is expecting JSF managed beans to
do CDI @Inject. maybe MyFaces implementation does allow for this and does
'not' place assumption that JSF managedbean will 'never' have or allow for
CDI @Inject. I know, in my JSF/PrimeFaces/MyFaces/TomEE web app, I would
never try something like this. I would do CDI managed bean and do CDI
@Inject into other CDI managed beans. that is why i migrated 'from' JSF
managed beans to CDI managed beans, when I migrated from Glassfish/R.I. to
TomEE/OpenWebBeans.
also, the CDI @RequestScoped bean below,
@Named(editProfile)
@RequestScoped
public class EditProfileB {
looks more correct to me, since it is already a CDI managed bean doing the
following CDI @Inject,
@Inject
UserDataB udB;
@Inject
UserC userC;
@Inject
ImageC imageC;
maybe your JSF-managed ViewScoped bean is using CDI @Inject to reference
another bean, and the whole thing may be throwing MyFaces into a flux. but
i'm definitely not the expert here.
...my two cents. :)
Re: Random JSF error: no saved view state could be found
Hi!
I'm always open to comments and suggestions, but please try to provide a
fix or a solution.
That error happens both on CDI and ManagedBeanS. Excluding one and
guessing that the other one might be the problem shows that you didn't
actually get the bug.
If you don't know the other Tomee properties, please check Tomcat and
Tomee documentation. For Facebook4j, please use Google.
Best,
Mircea
On 10/1/2013 6:37 PM, Howard W. Smith, Jr. wrote:
responses inline, below.
On Tue, Oct 1, 2013 at 3:45 AM, Zmirc zmircmir...@gmail.com wrote:
set JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.session.**
StandardSession.ACTIVITY_**CHECK=true
set JAVA_OPTS=%JAVA_OPTS% -Dopenejb.session-context=http
these two are definitely interesting, even though you stated, earlier, that
you are not really doing much/any session-management logic/checks. i don't
know the purpose of standardsession.activity_check and
openejb.session-context=http, but 'session' says a lot (to me).
set JAVA_OPTS=%JAVA_OPTS% -Dfacebook4j.loggerFactory=**
facebook4j.internal.logging.**NullLoggerFactory
facebook4j? wow, never heard of that. interesting.
So...the error happens randomly (just sometimes to some users) for all
pages that modify information and are backed by a @ViewScoped bean:
I looked at your bean, and it is quite interesting that this (JSF)
'managedbean',
@ManagedBean(name = addItem)
@ViewScoped
public class AddItemB implements Serializable {
uses CDI to @Inject the following:
@Inject
UserDataB udB;
@Inject
ItemC itemC;
@Inject
ImageC imageC;
@Inject
UserC userC;
I don't know if MyFaces' implementation is expecting JSF managed beans to
do CDI @Inject. maybe MyFaces implementation does allow for this and does
'not' place assumption that JSF managedbean will 'never' have or allow for
CDI @Inject. I know, in my JSF/PrimeFaces/MyFaces/TomEE web app, I would
never try something like this. I would do CDI managed bean and do CDI
@Inject into other CDI managed beans. that is why i migrated 'from' JSF
managed beans to CDI managed beans, when I migrated from Glassfish/R.I. to
TomEE/OpenWebBeans.
also, the CDI @RequestScoped bean below,
@Named(editProfile)
@RequestScoped
public class EditProfileB {
looks more correct to me, since it is already a CDI managed bean doing the
following CDI @Inject,
@Inject
UserDataB udB;
@Inject
UserC userC;
@Inject
ImageC imageC;
maybe your JSF-managed ViewScoped bean is using CDI @Inject to reference
another bean, and the whole thing may be throwing MyFaces into a flux. but
i'm definitely not the expert here.
...my two cents. :)
Re: Random JSF error: no saved view state could be found
forgot to mention that I usually add 'private' to managed bean members that
I reference via @Inject, so in my app, I would do the following:
@Inject
private UserDataB udB;
@Inject
private ItemC itemC;
@Inject
private ImageC imageC;
@Inject
private UserC userC;
also, I would change the JSF-managed-bean to a CDI-managed bean.
FYI, MyFaces 2.2.0 (snapshot) is available, now, for download-n-testing,
and MyFaces 2.2.0 (snapshot) has CDI @ViewScoped.
also OmniFaces 1.6 has CDI @ViewScoped, too, for MyFaces 2.0.x and 2.1.x;
i'm using that in production, and it has been working great with TomEE
1.6.0 and MyFaces 2.1.12.
On Tue, Oct 1, 2013 at 12:37 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
So...the error happens randomly (just sometimes to some users) for all
pages that modify information and are backed by a @ViewScoped bean:
I looked at your bean, and it is quite interesting that this (JSF)
'managedbean',
@ManagedBean(name = addItem)
@ViewScoped
public class AddItemB implements Serializable {
uses CDI to @Inject the following:
@Inject
UserDataB udB;
@Inject
ItemC itemC;
@Inject
ImageC imageC;
@Inject
UserC userC;
I don't know if MyFaces' implementation is expecting JSF managed beans to
do CDI @Inject. maybe MyFaces implementation does allow for this and does
'not' place assumption that JSF managedbean will 'never' have or allow for
CDI @Inject. I know, in my JSF/PrimeFaces/MyFaces/TomEE web app, I would
never try something like this. I would do CDI managed bean and do CDI
@Inject into other CDI managed beans. that is why i migrated 'from' JSF
managed beans to CDI managed beans, when I migrated from Glassfish/R.I. to
TomEE/OpenWebBeans.
