Figured this one out, thanks Igor. Our pages extended from a base page that was manually injecting services -- I'm not sure why -- so the components were getting the proxy and pages were getting the direct instance. I fixed this and things work perfectly now.
Thanks for your help. On Fri, Jun 26, 2009 at 12:39 PM, Igor Vaynberg<[email protected]> wrote: > it is wicket-guice module that wraps the service that is retrieved > from guice with a serializable proxy, not guice itself. > > this module treats pages and components exactly the same way because > page IS A component. i am not sure why pages work differently for you > if you use the same @Inject annotation and letting the module do the > injection for you rather then guice itself. > > if you take the service that is causing a problem on a page and inject > that into a component it works fine? can you verify that the thing > being injected into a page is the wicket serializable proxy rather > then the direct instance? > > -igor > > On Fri, Jun 26, 2009 at 10:20 AM, Aaron Dixon<[email protected]> wrote: >> But the nice thing about Guice/Wicket is that you don't have to >> concern yourself with the serialization problem. And for my non-page >> components, injection works perfectly. (This is because Guice injects >> a *serializable* proxy not an actual instance of the service itself. >> On detach/serialization, the proxy is serialized and on >> deserializaiton/rehydration, Guice/Wicket will inject the >> proxy/service again.) >> >> So, to reiterate, my problem is that all of this works perfectly for >> me for any non-page components, but when I @Inject on a Page, the >> service that is injected is not a proxy and therefore not >> serializable... and therefore I get the serialization exceptions. >> >> Technically Guice IS injecting my service at the page level, it's just >> injecting the instance itself and not wrapping it a proxy, whereas it >> IS injecting serializable proxies for non-page components. Why? >> >> >> On Thu, Jun 25, 2009 at 2:04 PM, Mauro Ciancio<[email protected]> wrote: >>> On Wed, Jun 24, 2009 at 1:38 PM, Aaron Dixon <[email protected]> wrote: >>> >>>> >>>> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: >>>> Unable to serialize class: >>>> com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94 >>>> Field hierarchy is: >>>> 2 [class=com.mycompany.pages.MyPage, path=2] >>>> private com.mycompany.dao.MyDao >>>> >>>> com.mycompany.pages.MyPage.myDao[class=com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94] >>>> <----- field that is not serializable >>>> at >>>> >>>> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:342) >>>> at >>>> >>>> org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:610) >>>> ... >>>> ==== >>>> >>>> Has anyone else noticed this? >>>> >>> >>> Yes, it happens because the injected class isn't Serializable and when >>> your page >>> is serialized the exception is thrown. >>> You could use for example a >>> LoadableDetachableModel<http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/model/LoadableDetachableModel.html>to >>> detach your DAO when >>> your page is serialized. >>> Guice also comes with an interface named Provider<T>. This could helps >>> because it >>> dont hold a reference to your un-serializable object. >>> >>> Example: >>> >>> class MyPage extends Page { >>> LoadableDetachableModel daoModel = new loadable() { >>> object get() { >>> return new dao(); >>> } >>> }; >>> >>> void something() { >>> mydao = daoModel.getObject(); >>> //stuff >>> } >>> >>> void ondetach() { >>> super.ondetach() >>> daomodel.detach(); >>> } >>> } >>> >>> HTH >>> Cheers! >>> -- >>> Mauro Ciancio >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
