Hi Vincent Here are some comments inlined... Le 18/05/2010 19:24, Vincent Massol a écrit :
As OSGi use the service layer (µservice as we should say now) to interoperate, everything that is service can talk with another service. It doesn't matter if your µservice was produced by hand, with iPOJO, Blueprint (any OSGi component model you want). So if the XWiki programming model produces/consume µservices other µservices can be used too, they just have to conform to the µservice API/Interface.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
OBR is not something that will help to download and install remote bundles.With a "naked" gateway, you can always download and install remote bundles (http://....). The goal of OBR is to help installling a *set* of bundles with dependencies between them. For example, if Bundle A depends on Bundle B, you should have to manually download and install 2 Bundles.
With OBR, you just "say": "I want A installed" and B will be installed too.
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
In that case, It's possible to have the webapp launching an OSGi gateway.You could have the core classes in the WEB-INF/lib/*.jar (or WEB-INF/classes) and have a selected set of packages (from the core) exported by the gateway (through the System Bundle). So your extensions (standard bundles) can use the packages from the core. The only thing you cannot do with that case is to update the core classes (since they are not really in a bundle, but considered as part of the JDK packages).
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.
You're absolutely right, it's easier when everything is OSGified.
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.
Agree, OSGi will help you to bind a bundle to an exported package using a specified version (may be a version range). If what you produce is a wiki page, not some java code, it will be more difficult to requires a given package version... As OSGi targets Java, it's more usable (and there are more tools available) if you write directly Java code: Bnd can automatically deduce your imports and service-oriented component models handles dynamic service dependencies for you.
Cheers --Guillaume
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? 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
<<attachment: Guillaume_Sauthier.vcf>>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
