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

Reply via email to