19 May
2010
19 May
'10
8:25 a.m.
On May 19, 2010, at 7:49 AM, Caleb James DeLisle wrote:
+1 The plan sounds good based on the small research I
did earlier.
I like using/adapting the current component manager (at least for now)
because it is small and easy to understand. As I understand OSGi and
299 implementations are large with more to go wrong or introduce security
problems so converting should be taken with some caution.
A little clarification:
Adding an extension will require PR?
No, I don't think this is needed (except for pages requiring PR obviously but we
should have some warning when importing these pages).
XARs will be dependent on other XARs?
Yes, if a page in one XAR requires a page from another XAR to work.
The general mechanism is not fully defined yet but one idea is to have a special
"virtual" artifact for each application and its pom would have dependencies on
XAR files and jar libraries.
Will the dependencies be automatically downloaded?
Yes, transitively.
Is this something for farther in the future?
Nope, this is for step 1.
Thanks
-Vincent
Caleb
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.
Also
it sounds like a permgen nightmare.
> 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/