It seems that Wicket should not be burdened with this tracking that is only used in OSGi configurations. Another issue is that an admin will use OSGi interfaces to swap out bundles, not wicket interfaces. OSGi is going to use the BundleActivator of the component bundle to stop it, and it won't know to tell the wicket core service anything about what it's doing to the component bundle. Thus it needs to know whether and/or when it can unload.
Once a bundle is in the STOPPING state, it's no longer an active service, so it cannot call other services or be called by them. Yet, the tracking needs to be updated so the blocked call to stop can unblock, hence the weak reference collection. On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
