Looks simpler solution. If it works OK then we can commit it in SVN. You are right, wicket-bundle just combines -util.jar, -request.jar and -core.jar into one. We can create a new wicket-osgi project in wicketstuff that will provide the integration code, like OsgiClassResolver and whatever else is needed.
On Fri, Jun 24, 2011 at 11:22 AM, Brian Topping <topp...@codehaus.org> wrote: > 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 > > -- 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
