| sp_redeploy creates class cast exceptions for session attributes [message #59753] |
Mon, 06 February 2006 13:39  |
 Wolfgang Gehner
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
If I have, say, a bean in a user session, and do sp_redeploy, retrieving
the bean creates a class cast exception, for fairly obvious reasons. Only
Tomcat WAR reload clears the situation.
Ideally, the user in the old session should be able to continue working
with references to the old version of the app. Maybe, that's a bit much to
ask for the moment, and sessionBindingListeners could be used to track and
invalidate affected user sessions or session objects. A can of worms?
I don't know what OSGi says about invalidating sessions, if anything, but
if we do nothing, we can just go back to WAR deployment :-)
A feature request?
|
|
|
| Re: sp_redeploy creates class cast exceptions for session attributes [message #59801 is a reply to message #59753] |
Mon, 06 February 2006 16:17  |
Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
"Wolfgang Gehner" <wgehner@infonoia.com> wrote in message
news:75f591bac642a3f265345b2de550252e$1@www.eclipse.org...
> If I have, say, a bean in a user session, and do sp_redeploy, retrieving
> the bean creates a class cast exception, for fairly obvious reasons. Only
> Tomcat WAR reload clears the situation.
>
> Ideally, the user in the old session should be able to continue working
> with references to the old version of the app. Maybe, that's a bit much to
> ask for the moment, and sessionBindingListeners could be used to track and
> invalidate affected user sessions or session objects. A can of worms?
I thought about this one a while ago. It's nasty and the OSGi HttpService
does not deal with it.
It poses a problem not just for sp_redeploy, but also in any situation where
the bundle defining the Class is updated.
I think this problem is present for all of the attributes (Context, Request,
Session) where the stored object originates from a bundle. I was thinking
that something clever with Attribute listeners could be done but I haven't
given it a lot of thought.
>
> I don't know what OSGi says about invalidating sessions, if anything, but
> if we do nothing, we can just go back to WAR deployment :-)
ouch!
> A feature request?
>
probably fair game.
|
|
|
|
| Re: sp_redeploy creates class cast exceptions for session attributes [message #60175 is a reply to message #60110] |
Tue, 07 February 2006 16:04 |
| Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
Open up a bug and lets looks at this.
I think this can be directly supported in the servlet bridge fairly easily.
"Wolfgang Gehner" <wgehner@infonoia.com> wrote in message
news:8d6bab35f06bce0f74775ea97624d9af$1@www.eclipse.org...
> I can use a HttpSessionAttributeListener to see what objects are added to
> which user sessions.
>
> My preferred strategy is to
> - invalidate user sessions which have attributes set by a redeployed
bundle
> - or remove session attributes set by a redeployed bundle.
>
> For that strategy, all I need now is a way to get from the class in the
> session to the name of its bundle, something like
> class.getClassLoader().getBundleId() Any ideas out there? Or am I
> thinking too simple?
>
> In my case the class name is actually the attribute key, which might
> simplify things.
>
>
>
|
|
|
|
| Re: sp_redeploy creates class cast exceptions for session attributes [message #61086 is a reply to message #60110] |
Fri, 10 February 2006 02:44 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
"Wolfgang Gehner" <wgehner@infonoia.com> wrote in message
news:8d6bab35f06bce0f74775ea97624d9af$1@www.eclipse.org...
> I can use a HttpSessionAttributeListener to see what objects are added to
> which user sessions.
>
> My preferred strategy is to
> - invalidate user sessions which have attributes set by a redeployed
bundle
> - or remove session attributes set by a redeployed bundle.
>
> For that strategy, all I need now is a way to get from the class in the
> session to the name of its bundle, something like
> class.getClassLoader().getBundleId() Any ideas out there? Or am I
> thinking too simple?
Check out PackageAdmin.getBundle(Class)
> In my case the class name is actually the attribute key, which might
> simplify things.
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03844 seconds
] 
Search
Help
Register
Login
Home
