I put two methods in my BB that I understand should be called during the
serialization/deserialization process that <t:saveState> invokes.
I do not see in my Tomcat log that these two methods are being called. Does
this mean that <t:saveState> is indeed not working in my case?
The methods I put in my BB that the xhtml references (which contains
<t:saveState> are as follows:
private void readObject(ObjectInputStream stream)
throws IOException, ClassNotFoundException {
stream.defaultReadObject();
System.out.println("--- Deserialization (saveState):
PtGroupAdmin.readObject() ---");
}
private void writeObject(ObjectOutputStream stream)
throws IOException, ClassNotFoundException {
stream.defaultWriteObject();
System.out.println("--- Serialization (saveState):
PtGroupAdmin.writeObject() ---");
}
The fact that neither of these are called in my BB indicate that
<t:saveState> (for some reason) is not working in my project. I am sure it
works, but there may be some odd reason (config) it is not working here.
Any help would be appreciated. I inherited this framework and am trying to
find out if it works like people think that it is. Would putting these two
methods in my BB be in indication that the <t:saveState> and Serrialization
are working correctly or am I on the wrong path?
Simon Kitching-3 wrote:
>
> SimonSays wrote:
>> So why is it that I read if you use <t:saveState> that the BB must
>> implement
>> Serializable? So something that is serializable does not necessarily
>> write
>> out a file system file, but can store the file in memory as well?
>
> There are three options for saving a component tree:
> (a) serialize it and send it to the client browser as a hidden input field
> (b) serialize it and store it into the webserver's http session
> (c) store it into the webserver's http session unserialized.
>
> For (a) and (b), the object being saved must implement
> java.io.Serializable, or javax.faces.component.StateHolder.
>
> Option (c) is easier, but doesn't work with clustering, doesn't support
> "hot restart" and doesn't allow the webserver to store a user's http
> session on disk when memory gets short. It is therefore not the default;
> you need to explicitly enable this mode (and I wouldn't recommend it).
>
>>
>> Also if STATE_SAVING_METHOD set to "server" saves a "file" the the
>> HttpSession what does STATE_SAVING_METHOD set to "client" do differently?
>
> MyFaces never "saves a file". It just places an object (which may be a
> serialized object [b], or an unserialized one [c]) into the http
> session. What the webserver does with a user's http session is up to it.
>
> You may need to read about serialization; it is NOT just about writing
> data to files on a disk.
>
>>
>> how do I tell if the whole object is being serialized (state saved)
>> rather
>> than just some property in a bean? I may hit the breakpoints but I want
>> to
>> see the actual data somewhere and watch it get restored as well. I do
>> not
>> believe <t:saveState> is working but do not know why. I need to know for
>> sure that it is not working before I go and try to find out why.
>
> I can't think of any easy way to do this. Java serialization is pretty
> complex, and not the sort of thing I would want to trace through. Maybe
> you could define your own readObject/writeObject methods that just
> delegate to the standard implementations to give yourself somewhere to
> place your breakpoints but I've never needed to do that.
>
> I assure you that t:saveState does work for many thousands of other
> people out there (including myself).
>
> Regards,
>
> Simon
>
>
--
View this message in context:
http://www.nabble.com/%3Ct%3AsaveState%3E-problems-%28not-working---have-tried-everything%29-tf2963422.html#a8377572
Sent from the MyFaces - Users mailing list archive at Nabble.com.
