Arthur, Thanx for sharing your experiences! Please find my comments below ...
Heiko 2009/7/29 Arthur <avand...@gmail.com> > > Hi all > > I'm completely new to Lift (and Scala) so I'm not yet very familiar > with the Lift-specific needs regarding modularization. But I just come > from an OSGi project and would like to share two experiences I've had: > > * Usually OSGi handles classloading very well. Where you can run into > problems is when third-party libraries do their own classloading > wizardry. I've spent quite some time hunting down exceptions like > "java.lang.Object Class Not Found". There are solutions and > workarounds for such problems. (The most important ones would be > passing along the classloader of the current thread to a library doing > its own classloading stuff, importing more classes from that library > in case of broken classloading chains and using the bootdelegation > runtime parameter of the OSGi framework.) How well these would work in > combination with Lift and Scala I don't know. I am very focussed on Lift being a good OSGi citizen! Hence Lift itself shall use OSGi properly without workarounds. There will be enough of them for third-party libs ... > > * People have grown tired of keeping manually track of OSGi services > and bundles by subscribing to the service registry or by using a > ServiceTracker. Several solutions exist to automatically keep track of > dependencies and dynamically start and stop bundles. The one I've used > are OSGi's own Declarative Services. But there exist several other > solutions to look at: Eclipse Extensions, Spring-OSGi, iPOJO and > possibly more. I've chosen Declarative Services because they are part > of the OSGi Service Compendium and seem to be comparatively > lightweight, but everything else probably would have worked just as > well. Internally I am planning to use the OSGi API or better ScalaModules ( www.scalamodules.org), in order to keep the footprint small and avoid bugs from DS, DM, etc. But of course people can use any declarative approach for their bundles. > > > I do like OSGi because I think it adds modularization functionality to > Java which it has really been missing. Whether it's the right tool to > use for Lift I gladly let the Lift cracks decide. I clearly don't > know. > > I hope this was at least tangentially helpful. > Cheers > > Arthur > > On Wed, Jul 29, 2009 at 8:33 AM, Heiko > Seeberger<heiko.seeber...@googlemail.com> wrote: > > Hi all, > > This is a very good discussion! > > As I am trying to provide OSGi support for Lift, I already encountered > this > > booting/resolving issue. If we could go for OSGi-only this would be a > > straightforward task (like Stephen described), but we have to support > both > > worlds: Static monolithic non-OSGi and dynamic modular OSGi. > > I have not yet come up with a solution (could someone please sell me some > > spare time) but I know for sure there have to be some major changes to > > resolving/classloading and static-ness (e.g. LiftRules only lets you add > > stuff, but OSGi requires stuff to be removed on stopping/uninstalling > > bundles again) if we want proper OSGi support. > > Any ideas/discussions are very welcome! Go on! > > Cheers > > Heiko > > 2009/7/29 stephen goldbaum <stephen.goldb...@gmail.com> > >> > >> Classpath management is one of OSGi's features. Another is dynamic > >> service registry and dependency management. So following that route, > >> the Lift framework would define an interface that exposes much of what > >> is currently found in Boot. Modules (OSGi bundles) would create > >> implementations of that interface and register them during startup > >> (fortunately the details are usually handled automatically). Lift > >> would also define a manager class that listens to the registry and > >> does whatever bookkeeping is required when modules come and go. > >> Eclipse RCP is a great example of this in action. Note that defining > >> a framework on top OSGi can also be a slippery slope. RCP is a good > >> example of that as well; it's an extensive framework on top of OSGi. > >> So, the question is whether it's worth turning what is currently a > >> straightforward boot process into something that is more modular > >> though more complicated. If so, a good first step would be to define > >> that manager class and interface since these could be wired together > >> by any means (Scala, OSGi, Spring, etc.) without necessarily branching > >> too far. I can take a look if you all think it's worth it (and if > >> Heiko hasn't already). > >> > >> -Stephen > >> > > > > -- My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: www.scalamodules.org Lift, the simply functional web framework: liftweb.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
