wicket-bundle appears to be simply using assembly plugin to mash all the jars together.
I haven't tested it yet, but I believe https://github.com/topping/wicket/commit/b120bdd4e6b7b085f2644aab1f77b3d40558c967 is a better solution. Haven't found OsgiClassResolver yet, but it's late here and I'm going to bed. On Jun 24, 2011, at 12:50 AM, Martin Grigorov wrote: > OsgiClassResolver will be in wicket-bundle.jar (the one in wicketstuff). > The user application will use it by: > > MyApp#init() { > super.init(); > getApplicationSettings.setClassResolver(new OsgiClassResolver()); > } > > > On Fri, Jun 24, 2011 at 10:46 AM, Brian Topping <topp...@codehaus.org> wrote: >> 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 >> >> > > > > -- > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
