Where to store the session object in a Standalone application?

Question

I'm having a session object that does NOT implement the java.lang.Serializable. (its a legacy application, and now I can't go and change the code)

Is there any way where I can store the session object some where and later GET BACK THE SAME STATE in a STANDALONE application.

One thought is to use RMI. Is there any better way of achieving this.

EDIT: The Legacy application has APIs that give me the Session object. On the Session object, I'll be invoking the methods. Getting the Session object is really an expensive operation. So, I would like to Store it some where for any subsequent actions until the Session is valid.

Thank you :)

Answer 1

Let's assume that you can interrogate your session object to determine its state, and that given that state you can create a new session object that is the equivalent. Then you need a helper class, each instance of which is associated with a session object and which is serializable. You write the serialization of the helper class to store the state of the session, and that when you create a new one by serialization it creates the session.

Answer 2

From the question I assume that you can add code to the outer edges of the applications but that there are everywhere "Beware of the JabberWock" signs.

If it is not serializable then the object will probably contain references to intrinsically unserializable stuff like services, stateful beans, ... and other stuff which only makes sense in the container. Now normally most of this stuff you probably wont need outside the container.

RMI will not solve your problem, because then the payload must be serializable, back to square 1.

A pragmatic approach could be to use a simple XML generator like XML Digester of Apache Commons if it still exists, or some simple JSON generator, and pick the data from the Session you need in the standalone app and dump it in a tree which makes sense.

Answer 3

If the session object does refer to stuff that is non-serializable (not just in terms of the interface but rather in terms of what kinds of non-serializable stateful instances it holds onto), then you will have a hard time reconstructing it in a meaningful way.

If this is not the case, then you can use XStream to serialize it, even if Serializable was not implemented.

Luckily, it's pretty easy to test: if your reconstructed session object works for you, you're in the clear.