myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zmirc <zmircmir...@gmail.com>
Subject Re: Random JSF error: no saved view state could be found
Date Wed, 16 Oct 2013 06:52:26 GMT
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. <smithh032772@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. <
>> smithh032772@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.
>>>


Mime
View raw message