Wicket has org.apache.wicket.application.IClassResolver. The mentioned ticket earlier has OsgiClassResolver impl
On Fri, Jun 24, 2011 at 10:39 AM, David Leangen <wic...@leangen.net> 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 > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
