Hi, Leonardo!

I'm very glad to hear that. Thanks for willing to help.
A small comment: the error appeared with both ways of storing the state: server and client. I switched to client hoping that it may fix it, but it didn't make any difference.

After a few weeks with Majorra, that error didn't appear anymore.
How could I help with this bug? Reproducing it is not something I could do, because that's the actual problem: I didn't figure out how to reproduce it.

What I could do is to isolate the classes & jsf files in use for that bug, then put them in a sample project.
Would that be ok? What else could I do?

Best regards,
Mircea

On 10/16/2013 3:27 AM, Leonardo Uribe wrote:
Hi

I have checked the code inside MyFaces using jmeter and changing to client
side state saving, enabling/disabling encryption and the code is ok.

Definitively all the code related to state saving is ok, and the issue you
have in your application should be something very specific, maybe not
related to MyFaces.

The only way to know what's going on is doing the steps previously
mentioned in your application. One option I can imagine is it could be a
hidden exception thrown in some place when the view is restored, that is
later hidden with a view expired exception. It could be some object
attached to the component tree, or a view scope bean that does not
implement serializable interface. I have done the best I can to investigate
it, but at this point I have to say it is up to you to help us to discover
what's going on.

regards,

Leonardo Uribe


2013/10/1 Howard W. Smith, Jr. <smithh032...@gmail.com>

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.


Reply via email to