On May 19, 2010, at 3:06 PM, Guillaume Sauthier wrote: > > > Le 19/05/2010 14:44, Vincent Massol a écrit : >> On May 19, 2010, at 2:02 PM, Guillaume Sauthier wrote: >> >> >>> Hi Vincent >>> Here are some comments inlined... >>> >>> Le 18/05/2010 19:24, Vincent Massol a écrit : >>> >>>> 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 >>>> >>>> >>> 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). >>> >> yep >> >> >>> 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. >>> >> yep >> >> >>>> 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. >>> >> Yes, that's actually what I meant by "installing remote jars" (the jars + >> their deps) but I should have been more explicit :) >> > > Yep, I've understood what you meant when you were comparing with Maven3 > Embedder (making clear that you talked about dependencies) :) > >> >>>> 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. >>> >> Yes that could be done. We'd need to use the >> Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA config property and manually list >> all packages (this is a pain!). > > Not all packages, only the ones you want to be exported (basically your APIs). > In fact, you'll choose to export the packages that you think could be used by > extensions.
Yes but this is still some hard work since anytime a new API is introduced we'll need to remember to update that configuration. >> I guess an alternative would be to create a xwiki core bundle that is empty >> except for Bundle-Classpath in its manifest, generated by the maven bundle >> plugin and pointing to WEB-INF/lib/*.jar. >> > > Hmm, not sure it will work. > Bundle-Classpath refers to some inner jar file theoretically ... >From what I understand from http://www.aqute.biz/Blog/2007-02-19 it should >work I think. >>> 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). >>> >> Yes but that's acceptable I think and is not our primary need. >> > > You'll need to simply reload your webapp with the new core classes Yes. >>>> >>>> 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. >>> >> Note: I like what I saw in OSGi and I still think one goal of xwiki should >> be to integrate with OSGi (or with the JSR294 to be more generic, if that >> JSR is implemented one day... ;)). It's just that for the Extension Manager >> use case, I'm not sure we need OSGi from the onstart. >> > > This time, it's me that doesn't really know what will go in this > ExtensionManager, and more generally, what is an Extension :) > All depends of what extensions are. It's a mix of wiki pages, jars containing xwiki component implementations (like a xwiki java macro) and external jars (third party libraries). See http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager for more details of what we'd like. Note that I need to update this page since Thomas has almost convinced me that we don't need a super XAR format and that we can keep the XAR format for wiki page as it is now and not have a single jar/zip by using a special empty artifact made only of a POM listing what an extension is (ie a list of dependencies on XARs and jars). > If you have a small core and everything else provided as extensions, putting > OSGi from the onstart may be a good choice. > If extensions are java classes (that can be seen as services), using OSGi > just for them also may be a good soft introduction to OSGi. > If extensions are not java code, OSGi is a bad idea :) We have both (and code can be provided by wiki pages in the form of scripts and macros) but we cannot have different versions of wiki pages right now inside a single xwiki instance (I'm not talking about page history but about branches, each having its history). Another problem I mentioned would be to decide what classloader to use when executing a {{script}} macro. Thanks -Vincent >> Thanks for the info Guillaume, >> -Vincent >> >> PS: I'm still discovering all this and I'm not yet 100% sure of what I say. >> There's a little nagging thought in the back of my head that tells me that >> going with OSGi now is the best thing to do even though we might not need >> all its power (and complexity) right now but that it would be easier to >> shift now than later... ;) >> > > I understand, moving to OSGi for JOnAS has been a long work (and still not > completely finished to some aspects), but we started with a non modular > architecture, spaghetti code, ... :'( > In your case, I've understood that you have clean APIs, already have modules, > so the move should be easier :) > > --G > >> >>> 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
