i think the frameworks should track this. this way wicket can track what it is serializing and when it is letting it go. jetty can keep track of what it has in its http session.
the serialization bundle should provide a way for bundles to tell it "i am holding on to class A from bundle B" and i no longer care about class C from bundle D" -igor On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping <topp...@codehaus.org> wrote: > Good point. This could be handled by the serializer maintaining a > WeakHashMap of the sessions that use a particular bundle and blocking in the > bundle activator's stop method until the list is empty. > > But if a user was busy for an extended period, like some kind of automated > scraper or monitor that ended up having the session open for days, the check > would have to be more granular than the session. Which seems like it's going > to be different between 1.4 and 1.5 because of the migration from pagemaps. > > On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote: > >> something else to consider - where this gets even hairier :) >> >> user accesses a page that has a component from bundle A, the page is >> serialized. >> admin upgrades bundle A which has a new version of the component - >> that is not compatible serialization-wise >> user click back and the page needs to be serialized - error >> >> what is needed here i some way to veto a bundle/version removal until >> all web sessions that access components in those bundles have timed >> out. this is not really wicket-specific, more web specific as web apps >> can stick objects into http session... >> >> -igor >> >> >> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping <topp...@codehaus.org> wrote: >>> >>> On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote: >>> >>>>> what is really needed here is someone taking the time to build a >>>>> generic serialization mechanism for osgi. wicket's serialization is >>>>> pluggable so it can be hooked into that. >>>>> >>>> >>>> I'll take a look at the patches, play around with the code and find out if >>>> I'm one the wrong track or not... If I end up with anything interesting >>>> enough, I'll get back or attach another patch. >>> >>> I'm also taking a look at it. >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
