On May 18, 2010, at 7:24 PM, Vincent Massol 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).
Also note that having a single classloader for the moment solves the problem of
having a wiki page using script macros to access classes located in extensions.
With classloader isolation it's more complex and we would need something like
{{script extension="extensionid"/}} so that the extension's classloader is used
when evaluating the script macro.
Thanks
-Vincent
>
> WDYT?
>
> 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/
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
