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. * 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. 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 >> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
