Re: RCL, Session and ClassCastException

[Robin Wyles]

On 29 Dec 2007, at 20:01, Reinhard Poetz wrote:

Torsten Curdt wrote:

On 29.12.2007, at 19:40, Reinhard Poetz wrote:

Robin Wyles wrote:

Hi,

When developing using the RCL it seems that after I update any file that triggers a reload (e.g. sitemap) any references in my Java code to objects stored in the current session result in a ClassCastException. Debugging shows that the object is still there in the session after the reload, and it is of the correct class, so does anyone know why I should get this error?

The object that you put into the session is loaded by one classloader and then after a reload you cast it using another one.

Correct. A classloader is somewhat like a namespace in xml.
 <a:tag/> != <b:tag/>

Objects can only be casted if their classes have been loaded by the same classloader. No matter they are maybe loaded from the same class file.

Reinhard, Torsten - thanks for your explanations...

This seems to be a bug in the reloading classloader or the way how we use it. Unfortunatly I haven't had the time yet to create a test case that demonstrates the problem in an isolated environment so that the Commons JCI guys can have a look at this problem (if it's their problem).

This could be changed

That would be really great!!!

I would second this, and if it it can't be done easily I think this issue with the RCL needs to be highlighted in its documentation.

...but it's a bit of an effort and adds to the complexity.

I think it would be worth changing the implementation because there are many people that can't or don't want to avoid the usage of sessions.

Thanks,

Robin

And also, why should one avoid the usage of sessions? For things like authentication/access control I'm not sure what alternative I could use.

smime.p7s
Description: S/MIME cryptographic signature