Well, I was able to isolate the problem from the Resin handling of
sessions, so it seems there's something wrong with my class and Java
serialization. The class that is shown in the error is not causing the
problem on its own, that's why my first standalone tests worked, but it
is stored inside the session wrapped in another class and this
combination is somehow failing. I cannot test it outside Resin, as this
class is created from information from HttpSession etc. but as I said
the problem seems to be in the standard (de)serialization of that set of
I tried serializing to XML and I ended up with an empty XML file, no
errors reported, and serializing produces a file that "looks" fine but
I'm unable to deserialize it.
I'll have to go back to CVS history and apply changes one by one to see
what change triggers the error... oh well.
Thanks for your help,
Scott Ferguson escribió:
> On Sep 4, 2007, at 10:27 AM, Daniel Lopez wrote:
>> First thing I did was to clean up all the deployment directory, making
>> sure the WEB-INF/sessions directory was removed, and session lifetime
>> is 30min, so they shouldn't have survived all the weekend in any case
>> I tried with Resin 3.1.2, just in case, and the result was the same. I
>> downloaded Resin source and built the resin.jar from scratch adding
>> some debugging info and I ended up at the readObject() call. So it
>> seems for some weird reason that de-serialising that object inside a
>> Session fails. However, I tested the serialise/de-serialise process
>> using the same JVM on the class giving the errors and I had no problem
>> doing it. Weird.
> Can you try changing the serialization-type to hessian:
> <session-config serialization-type="hessian"/>
> I'm not sure that it will change anything, but it might give a
> different error message that might help.
>> Is the srun.db file in some kind of format one can easily grasp?
> Not really. It's a virtual filesystem/database-row structure. There
> are inodes and fragments, and indirect blocks and all sorts of nasty
> (It does support a JDBC API, though. So if the hessian change
> doesn't give enough information you could copy it to another
> directory, and launch a jdbc driver
> com.caucho.db.jdbc.ConnectionPoolDataSourceImpl with <path>foo</
> path>. I wouldn't recommend it, but it's possible.)
> -- Scott
resin-interest mailing list