On Tue, May 18, 2010 at 19:24, Vincent Massol <[email protected]> wrote: > Hi devs, > > I've explored enough of OSGi to get a handle of how it works and what it > would mean to use it for XWiki as the basis for our Extension Manager (Thomas > helped me with this too). > > The executive summary is that I don't think we need to use OSGi right now for > the Extension Manager and we can defer its usage for later. > > Let me start by listing what would OSGi bring for XWiki: > 1) Known framework with good documentation, books, etc > 2) Users would be able to write extensions using OSGi programming model > (without using XWiki's programming model), this also means the ability to > reuse OSGi bundles inside XWiki > 3) ClassLoader isolation and thus ability to have several versions of classes > 4) OBR (Bundle Repository) for downloading and installing remote jars > > Now here are the problems found with OSGi so far: > A) Impedance mismatch with the webapp/WAR model (classloader and visibility > issues). Two examples: > - it would mean having a special directory somewhere, where to put the > bundles, and this means not going through the standard WAR deployment process. > - if we want to keep WEB-INF/lib in order to have a standard WAR deployment > then it would mean keeping for ex the core jars in WEB-INF/lib and using OSGi > only for extensions. However doing this is not really possible since it would > mean extension (OSGi bundles) would have Imports on core classes but this > won't work since core classes won't be OSGi bundles > B) In practice it's very hard to use OSGi with only a part of the modules > being OSGi bundles and another part being standard external libraries. > Everything must be OSGified for it to work well. > > In addition we might want not need the features listed above: > 1) Not really needed especially since we have the XWiki programming model > that we don't want to loose right now > 2) is a nice to have but not a requirement for the Extension Manager > 3) in practice it's going to be very hard to support multiple versions of > classes. Imagine for example an application A which is providing a macro in a > wiki page. Application B requires version 1.0 of A and application C requires > version 2.0 of A. How do we support that? OSGi won't help here since this is > about wiki pages. It's only helping for jars. The jar isolation could also > easily be implemented using a custom URL classloader without too much problem > IMO, but I'm inclined to say that we don't need to support multiple versions > in a first version of the Extension Manager. > 4) We can easily use the Maven 3 Embedder to download and install maven > artifacts into a local repository. This is convenient since we already deploy > our applications/modules to a maven repository. Note that the only > "difficult" part here might be searching into a remote repository; I don't > know if a maven api exists for this (but probably). In the worst of cases we > could use the Nexus REST API to provide this feature for now. > > And here's what I think we should do right now: > i) focus on the 2 features we need for the Extension Manager: > -- ability to install an application containing not only wiki pages but also > jars > -- ability to install an application from a remote repository > ii) then once i) is done focus on the upgrade part of the extension manager > > Implementation note: > - To implement i) we can do this easily I believe using a custom URL > ClassLoader (we already have one btw used in the script macro) that we pass > to the Component Annotation Loader when a new JAR is installed (in order to > register the components in that jar) + set that custom URL ClassLoader as the > new thread context classloader (for code that would use the thread context > classloader to load classes). > > WDYT?
Surprisingly I'm +1 ;) > > Thanks > -Vincent > > PS: I'd be interested to hear from OSGi experts what they have to say about > this since I'm an OSGi newbie and there might be stuff I have not > seen/realized. > PPS: I'm just realizing that the proposal in this mail is close to > Pomegranate's idea: http://www.caucho.com/projects/pomegranate/ Indeed Pomegranate sounds good if we can use it outside of Resin. > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
