IIUC, other frameworks allow for the injection of a classloader. Wouldn't that be enough?
We could then package an optional classloader just for that purpose. Cheers, =David On Jun 24, 2011, at 4:34 PM, Brian Topping wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
