I’m working on a large Java application that uses Wicket 1.5 together with Hibernate / JPA 2. Wicket has a standard rule that objects stored in the session must implement Serializable. We have an extra rule that JPA managed objects must not be stored in the session. Instead, JPA managed objects are loaded on each request through detachable models.
To complicate matters, it is legitimate to store an Entity object in the session provided that it has not been persisted yet. As a result, some of our classes already implement Serializable.
If I wanted to extend Wicket’s serialization test to detect objects owned by JPA, how would I go about it? Is this possible without a local fork of Wicket?
At my $dayjob we use something what you describe, and what I have presented at several meetups (see slide 23 and on). You don’t have to fork Wicket for that.
Basically what you do is copy the serializer checker code and modify it to include your check as well as checking for serialization errors. Then in the last phase of the request cycle you run your own serializer checker on the affected pages.
The check we created checks for our common base class, and wether or not the entity has ben persisted. If so, we fail the request. Additionally we have an Ajax callback in our base page that checks a session attribute to see if there was a serialization error. If so, we redirect to the error page with the serialization failure, to ensure that developers don’t ignore the entity in page hierarchy.
Here’s the meat of our checker (the
checkmethod rewritten from Wicket’s serializer check):For Wicket 1.5 we created our own
PageStoreManagerthat performs these checks (and a lot of other things, like enabling a server side browsing history for our users). We provided our ownRequestAdapterby overridingPageStoreManager#newRequestAdapter(IPageManagerContext context)and doing the serialization check in the adapter: