java.io.NotSerializableException
This kind of exception has usually a message in the root cause which shows the fully qualified class name of the class which doesn't implement Serializable
. You should pay close attention to this message to learn about which class it is talking about and then let it implement Serializable
accordingly.
Often, making only your managed bean classes serializable is not always sufficient. You also need to ensure that each of its properties is also serializable. Most standard types like String
, Long
, etc implement all already Serializable
. But (custom) complex types such as nested beans, entities or EJBs should each also be serializable. If something is not really implementable as Serializable
, such as InputStream
, then you should either redesign the model or make it transient
(and keep in mind that it will be null
after deserialization).
What is the difference when i use client and server
First some background information: Why JSF saves the state of UI components on server?
The main technical difference is that the client
setting stores the entire view state as the value of the javax.faces.ViewState
hidden input field in the generated HTML output and that the server
setting stores it in the session along with an unique ID which is in turn referenced as the value of the javax.faces.ViewState
hidden input field.
So, setting to client
increases the network bandwidth usage but decreases the server memory usage and setting to server
does the other way round. Setting to client
has however an additional functional advantage: it prevents ViewExpiredException
s when the session has expired or when the client opens too many views.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…