If by that you mean Wicket would be injected with something like the system classloader or wicket's classloader, it kind of breaks modularity. How would one upgrade wicket itself? There's no limitation to doing so, the new Wicket bundle can have dependencies in parallel with the old wicket bundle, but if the dependencies were holding on to the old wicket's classloader, seems like a problem.
On Jun 24, 2011, at 12:39 AM, David Leangen wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
