* Igor Vaynberg:
this is not a requiremenet of wicket per se but that of the servlet
containers. anything you keep in http session must be serializable. since
wicket keeps most of its entities in session they must be serializable.
I understand this for a session because it can be made
On 7/19/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Igor Vaynberg:
this is not a requiremenet of wicket per se but that of the servlet
containers. anything you keep in http session must be serializable. since
wicket keeps most of its entities in session they must be serializable.
* Eelco Hillenius:
On 7/19/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Why do we need Serializable here?
I agree you don't need it for application. However,
Application's meta data reuses the metadata classes that are
used for pages and session, where meta data
I just changed the log4j log level for wicket to DEBUG and now my
application craps out with the following error:
Internal error cloning object. Make sure all dependent objects implement
Serializable. Class: mystuff.wicketapp.MyWebSession
Am I to assume that the entire hierarchy of class
this is not a requiremenet of wicket per se but that of the servlet containers. anything you keep in http session must be serializable. since wicket keeps most of its entities in session they must be serializable.when you set level to debug you tripped this:
HttpSessionStore:47public void
Thanks for the quick response. Do you know if there's a way to tell Java
which parts of an object are vital during serialization and which can
be ignored. I'm thinking about how Detachable Models work.
Am I correct in assuming that if I do not correct this my app will
continue to work in a
There is a DEBUG level logger in wicket.protocol.http.HttpSessionStore
that tries to serialize any attribute that is set. The development
version - soon 1.2.1 - has a fix so that it doesn't depend on the log
level, but instead on an application setting:
if
On 7/18/06, Steve Moitozo [EMAIL PROTECTED] wrote:
Thanks for the quick response. Do you know if there's a way to tell Java
which parts of an object are vital during serialization and which can
be ignored.
yep, the transient keyword. Transient fields will not be serialized
(and thus null
Thanks for the quick response. Do you know if there's a way to tell Java which parts of an object are vital during serialization and which can
be ignored. I'm thinking about how Detachable Models work.not really sure what you mean or why you would have to do that. what is the usecase for having
i would be careful about using transient since you will have to implement null checks anytime you access that field.-IgorOn 7/18/06, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On 7/18/06, Steve Moitozo [EMAIL PROTECTED] wrote: Thanks for the quick response. Do you know if there's a way to tell
not really sure what you mean or why you would have to do that. what is the
usecase for having something that is not serializable in session?
As I trace this issue through my code it's becoming apparent that since
pages are added to the session any properties that is in a page that
isn't
well, now that you are aware of this going should get better.in case you are storing beans from other framework that are not serializable i really dont see an easy way. the creators of those projects should make sure their objects are serializable. the only thing i see that you can do is to create
12 matches
Mail list logo
