* 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
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 serializ
* 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 persis
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
> 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 seria
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
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 som
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
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 (Application.get().getDebugSettings().get
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 single
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 setAttrib
11 matches
Mail list logo
