Re: [xwiki-devs] [Discussion] OSGi POC result and base for the Extension Manager

19 May 2010

...
     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.

Yes, but in an ideal world you should not introduce new core APIs every 
days :)

...

     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.

I'm not convinced :)
I think the example Peter put on this page is what you could do if you 
were transforming a war into a bundle.
In the case we're discussing, we're talking about having a normal webapp 
that launch an OSGi framework.

...
    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.
        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.
 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).

An extension could be seen as a bundle (containing librairies and 
resources), importing some packages and providing some µservices (making 
them available for other to use them).

...

  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.

If you think in OSGi terms, something that you use is probably a 
dependency on a µservice.
So the wiki page would be "linked"/injected to/with the "script"
µservice.
The difficulty here is that the dependency is actually kind of hidden in 
the wiki page, it's not explicit (like an @Inject field for example).
It's easier when we start with a component model, because theses models 
are designed to explicitely declares dependencies so that a container 
can handle them for you.

What I have the habit to say is that : "OK, OSGi have a powerful 
Classloading model, but most of the time we should not touch or even 
think about ClassLoaders". When you look at µservices that run on top of 
OSGi, they're never using ClassLoaders, they always talk to other 
services through API.

I mean that ClassLoaders handling is the job of the OSGi framework.
The consummer service will be injected with a compatible dependency 
service (compatible in terms of packages, so versioned) and will just 
call the dependency, not worrying about ClassLoading issue.

--G

...
  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
 devs(a)xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Re: [xwiki-devs] [Discussion] OSGi POC result and base for the Extension Manager