Thanks for the pointer! Interesting discussion... I'm not an OSGi expert but using buddy class-loading techniques will (maybe) help here... Essentially, what I do is to have wicket as part of a basic bundle W that contains Wicket jar and then all other bundles contributing components, say A,B,C..., will declare bundle W as a buddy so W has no problems in reading classes from A,B,C... I don't think this is a best practice but it works and I haven't found any serialization problems...but maybe I just have being lucky. This solution is equinox specific but I think the standard has something similar to buddy-class-loading... .
Best, Ernesto On Fri, Nov 14, 2008 at 10:18 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote: > these are some notes on possible issues of using wicket with osgi > > > http://groups.google.com/group/brix-cms-discuss/browse_thread/thread/8e76b2749187d067 > > -igor > > On Fri, Nov 14, 2008 at 11:35 AM, Ernesto Reinaldo Barreiro > <[EMAIL PROTECTED]> wrote: > > I do not use PAX-Wicket. In fact, I use equinox OSGi extensions for > dealing > > with OSGi class-loading restrictions (the only problem I experienced with > > Wicket and OSGi)... Never found/had serialization problems mysleft... > Some > > advantage of this approach are: > > 1-I can (easily) use components I develop this way in > > non-OSGI environments as well: it was longtime ago that I took a look at > PAX > > but that time I had the impression that the code was too OSGi > dependent... > > please forgive me if I'm wrong, I have not intention to criticize the > work > > of others... > > 2-I do not have to touch/change wicket code... I have seen messages in > this > > list of people complaining about having to change wicket to use it with > > OSGi. Maybe I'm just making a limited-wrong use of OSGi > > > > I find this a "nice way" to develop applications because for development > you > > have Eclipse, and the included jetty related bundles, and for deployment > you > > can use Bridge-Servlet approach... > > > > Best, > > > > Ernesto > > > > On Fri, Nov 14, 2008 at 7:53 PM, Igor Vaynberg <[EMAIL PROTECTED] > >wrote: > > > >> osgi has some problems when it comes to serialization - a feature > >> wicket uses extensively. so beware. at least see pax-wicket for > >> possible solutions. > >> > >> -igor > >> > >> On Fri, Nov 14, 2008 at 10:45 AM, Ernesto Reinaldo Barreiro > >> <[EMAIL PROTECTED]> wrote: > >> > I would use OSGi. Each application a different bundle (jars) and a > main > >> > bundle (jar) that defines the services for plugin in new modules... > For > >> > instance a service to register your left menu entries... I have done > >> > something "similar" for an application I built sometime ago. With OSGi > >> you > >> > could make it completely dynamic with modules added/removed at runtime > >> > without having to stop you server. So, essentially it is what Igor > said > >> but > >> > OSGi would make it easier to manage the dynamic part. > >> > Best, > >> > > >> > Ernesto > >> > > >> > On Fri, Nov 14, 2008 at 1:45 PM, cresc <[EMAIL PROTECTED]> wrote: > >> > > >> >> > >> >> hi, > >> >> > >> >> Just eager to know if any of you had tried the following application > in > >> >> wicket. > >> >> http://www.nabble.com/file/p20499804/appl.jpg > >> >> > >> >> Core.war contains the login, usermanagement, layout etc. > >> >> m1, m2, m3 etc are smaller modules independent of each other. > >> >> From the core layout contained in core.war I should be able to launch > >> m1, > >> >> m2 > >> >> m3 etc.. If a new module m4.war is deployed, then I would like to > have > >> m4 > >> >> menu appear on the layout (basically menus constructed from values in > >> >> database table). > >> >> > >> >> Please provide some starters on how to build an application like > this. > >> >> > >> >> Thanks, > >> >> cresc > >> >> > >> >> > >> >> -- > >> >> View this message in context: > >> >> > >> > http://www.nabble.com/dynamic-application-from-diff-wars-tp20499804p20499804.html > >> >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
