WicketNotSerializableException due to Guice Provider/InjectorImpl

[Dan Retzlaff]

I'm using WARP to manage my Hibernate sessions, and like the examples
show, I'm using Provider<Session> in my serializable Wicket components
where appropriate. However, I'm getting a
WicketNotSerializableException which appears to trace back to this
Provider<Session> interface, implemented by
com.google.inject.InjectorImpl.

To be honest, the idea that a provider can be serialized,
deserialized, and used successfully (even on a failover machine?)
seems magical to me. Maybe I'm missing something fundamental.

Here's Wicket's error message, pointing to the InjectorImpl.

18:58:07,578 ERROR [Objects] Error serializing object class
com.xxx.page.admin.MyItems [object=[Page class =
com.xxx.page.admin.MyItems, id = 2, version = 0]]
org.apache.wicket.util.io.SerializableChecker
$WicketNotSerializableException: Unable to serialize class:
com.google.inject.internal.InjectorImpl$4
Field hierarchy is:
2 [class=com.xxx.page.admin.MyItems, path=2]
private java.lang.Object
org.apache.wicket.MarkupContainer.children [class=[Ljava.lang.Object;]
private java.lang.Object
org.apache.wicket.MarkupContainer.children[0]
[class=org.apache.wicket.extensions.markup.html.repeater.data.table.DefaultDataTable,
path=2:inactiveItems]
private java.lang.Object
org.apache.wicket.MarkupContainer.children [class=[Ljava.lang.Object;]
private java.lang.Object
org.apache.wicket.MarkupContainer.children[0]
[class=org.apache.wicket.markup.html.WebMarkupContainer,
path=2:inactiveItems:body]
private java.lang.Object
org.apache.wicket.MarkupContainer.children
[class=org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable
$1, path=2:inactiveItems:body:rows]
private java.lang.Object
org.apache.wicket.MarkupContainer.children [class=[Ljava.lang.Object;]
private java.lang.Object
org.apache.wicket.MarkupContainer.children[0]
[class=org.apache.wicket.markup.repeater.OddEvenItem,
path=2:inactiveItems:body:rows:1]
java.lang.Object org.apache.wicket.Component.data
[class=com.xxx.model.LoadableDetachableModelFactoryImpl$1]
final
com.xxx.model.LoadableDetachableModelFactoryImpl
com.xxx.model.LoadableDetachableModelFactoryImpl$1.this$0
[class=com.xxx.model.LoadableDetachableModelFactoryImpl]
private com.google.inject.Provider
com.xxx.model.LoadableDetachableModelFactoryImpl.session
[class=com.google.inject.internal.InjectorImpl$4] <----- field that is
not serializable

The offending class (InjectorImpl$4) has the following toString().

com.wideplay.warp.persist.hibernate.SessionProvider@7ecd0f45[sessionFactory:
com.wideplay.warp.persist.hibernate.SessionFactoryProvider@4e280ec[boundTo: ]]

Thanks in advance for any guidance you might have.

Dan

--
You received this message because you are subscribed to the Google Groups "warp-core" group.
To post to this group, send email to warp...@googlegroups.com.
To unsubscribe from this group, send email to warp-core+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/warp-core?hl=en.

[Dhanji R. Prasanna]

Im not sure what the wicket solution for this is, but I guess you could mark it as transient and then if null, refetch it from the injector?

I think this is better asked on the Wicket list...

Dhanji.

[Dan Retzlaff]

It turns out that Dhanji's suggestion is close to the recommended approach. The difference is that they use a JDK6/CGLIB proxy which wraps the transient object reference, and which knows how to refetch automatically during deserialization.

This page describes the situation and solution in detail for wicket-spring, which also applies to wicket-guice.

https://cwiki.apache.org/WICKET/spring.html

In my particular case, these proxies were being created for my Wicket-instantiated page's dependencies, but when Guice recursively injected those dependencies' subdependencies, this proxy creation process was circumvented. My solution was to refactor the Wicket-instantiated component to eliminate references to these non-proxied objects.

Sorry for the misdirected question to warp-core. I was under the incorrect impression that WARP's Session Provider was meant to solve this serialization problem in addition to providing a new Session for each HTTP request.

Thanks for the great open source project!

Dan