|
Why not just mark those container objects as transient?
Marking them as transient would get rid of the serialization exception, but unless theres some smart way of getting hold of the wrapped container objects (request, context etc.) when a WebContext implementation is de-serialized then it just moves the problem along.
I agree that it just moves the problem along, but it seems to me that moving it along is the appropriate response. You can't remove "Serializable" (especially not as long as ContextBase extends HashMap) so you need to leave the responsibility for the wrinkles to users of the library.
What else could be done? Reminds me of this thread:
http://marc.theaimsgroup.com/?t=113339368800002&r=1&w=2 I do agree with Niall that moving the problem along is probably not the right solution (i.e. a NotSerializableException might still be better than, say, an NPE after subsequent deserialization – from the "if its fatal, die quickly" camp). Perhaps note as a known issue for 1.1? Dennis Lundberg found that TestContextTestCase failed the serialization test with JDK 1.4.2_11 when checking out Chain 1.1 release candidate 1. This test passed with JDK 1.4.2_10 but fails with the later JDK and also JDK 1.3.1_04.
Changing the static "placeholder" object for properties to be Seralizable appears to have fixed this: |
|||||||||||||||||||||||||||||||||||||||||||||||||||
can be serialized and deserialized successfully.
However, there is an issue with the WebContext implementations – they subclass
ContextBase and inherit the "implements Serializable" contract, but they cannot
in fact be serialized because they wrap container objects (request, response,
context) that are not serializable. Therefore, I'm leaving this bug report open
as we explore potential solutions to that issue.