20 Jan
2009
20 Jan
'09
11:35 a.m.
Hello,
I am studying the component model and its impact on the whole architecture
and naturally I have been thinking about OSGI and the possibility to deliver
component bundles and load dynamically components into a running XWiki
server etc... I'm not an OSGI expert and speak about OSGI because this seems
to be the most supported standard around these "dynamic service bundles
management with classloader isolation blablabla" questions...
I've seen OSGI is already in your thoughts and I would like to know the
status of your studies.
The question of the OSGI runtime is not quite a problem to my mind...
The new component model is well fitted to the OSGI approach IMO...
The real question is how to mix the IOC model with the OSGI bundle...
Plexus is a pretty IOC container but has no OSGI extension (there seems to
be some works around classworlds but not clear and classworlds is not OSGI
anyway...).
Would you keep Plexus and add the required extensions so that it can be
easily used with OSGI without adding too much code each time you want to
create a new OSGI service bundle?
Would you think about using another IOC container which propose OSGI
extensions (Spring DM or other)?
Pascal
20 Jan
20 Jan
11:51 a.m.
Hi Pascal,
Good topic!
On Jan 20, 2009, at 11:35 AM, Pascal Voitot wrote:
Hello,
I am studying the component model and its impact on the whole
architecture
and naturally I have been thinking about OSGI and the possibility to
deliver
component bundles and load dynamically components into a running XWiki
server etc... I'm not an OSGI expert and speak about OSGI because
this seems
to be the most supported standard around these "dynamic service
bundles
management with classloader isolation blablabla" questions...
I've seen OSGI is already in your thoughts and I would like to know
the
status of your studies.
The status can be summarized as:
* Top priority: move all code to components and rewrite those that
need to be rewritten. We've started this and the next big step might
be the new model
* Don't introduce any dependency on a given component model and allow
different component models to be used.
* Find someone who has some OSGi knowledge to try making bundles for
xwiki components.
The question of the OSGI runtime is not quite a
problem to my mind...
The new component model is well fitted to the OSGI approach IMO...
The real question is how to mix the IOC model with the OSGI bundle...
Are there any problems you know of? Ideally for me we should have a
component descriptor for each component model we want to support. I
think OSGi support both Java activator but also descriptors (maybe
using spring osgi for that I don't know).
Plexus is a pretty IOC container but has no OSGI
extension (there
seems to
be some works around classworlds but not clear and classworlds is
not OSGI
anyway...).
Actually this is not quite true. Plexus guys have developed an OSGi
bridge (bidirectional as I understand it). I haven't seen nor tested
it though.
Would you keep Plexus and add the required extensions
so that it can
be
easily used with OSGI without adding too much code each time you
want to
create a new OSGI service bundle?
Would you think about using another IOC container which propose OSGI
extensions (Spring DM or other)?
I'm not OSGi expert but I think the best would be to use OSGi with a
component descriptor (but without Java code if we can).
Note that there's a maven plugin for OSGi which will generate OSGi
Manifest information from maven's pom.xml files.
Basically we we're just waiting for someone who's interested in trying
out making our components OSGi components.
I'm very eager to verify that we can easily create OSGi bundles out of
our existing components.
So if you're interested, I'd say go for it. We need to that exercise
and the sooner the better. I don't know enough to decide if we need
spring osgi or pure OSGi. Maybe you can tell us after you explore it?
Thanks
-Vincent
http://xwiki.com
http://xwiki.org
http://massol.net
1:09 p.m.
Excinting! Lots of ideas and arguments to explore...
I'm currently exploring OSGI for my professional and personal needs and I
think I'm going to use XWiki as my OSGI sandbox...
I will give some news alongside my studies so that we can exchange our
ideas!
Pascal
On Tue, Jan 20, 2009 at 11:51 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Pascal,
Good topic!
On Jan 20, 2009, at 11:35 AM, Pascal Voitot wrote:
Hello,
I am studying the component model and its impact on the whole
architecture
and naturally I have been thinking about OSGI and the possibility to
deliver
component bundles and load dynamically components into a running XWiki
server etc... I'm not an OSGI expert and speak about OSGI because
this seems
to be the most supported standard around these "dynamic service
bundles
management with classloader isolation blablabla" questions...
I've seen OSGI is already in your thoughts and I would like to know
the
status of your studies.
The status can be summarized as:
* Top priority: move all code to components and rewrite those that
need to be rewritten. We've started this and the next big step might
be the new model
* Don't introduce any dependency on a given component model and allow
different component models to be used.
* Find someone who has some OSGi knowledge to try making bundles for
xwiki components.
The question of the OSGI runtime is not quite a
problem to my mind...
The new component model is well fitted to the OSGI approach IMO...
The real question is how to mix the IOC model with the OSGI bundle...
Are there any problems you know of? Ideally for me we should have a
component descriptor for each component model we want to support. I
think OSGi support both Java activator but also descriptors (maybe
using spring osgi for that I don't know).
Plexus is a pretty IOC container but has no OSGI
extension (there
seems to
be some works around classworlds but not clear and classworlds is
not OSGI
anyway...).
Actually this is not quite true. Plexus guys have developed an OSGi
bridge (bidirectional as I understand it). I haven't seen nor tested
it though.
Would you keep Plexus and add the required
extensions so that it can
be
easily used with OSGI without adding too much code each time you
want to
create a new OSGI service bundle?
Would you think about using another IOC container which propose OSGI
extensions (Spring DM or other)?
I'm not OSGi expert but I think the best would be to use OSGi with a
component descriptor (but without Java code if we can).
Note that there's a maven plugin for OSGi which will generate OSGi
Manifest information from maven's pom.xml files.
Basically we we're just waiting for someone who's interested in trying
out making our components OSGi components.
I'm very eager to verify that we can easily create OSGi bundles out of
our existing components.
So if you're interested, I'd say go for it. We need to that exercise
and the sooner the better. I don't know enough to decide if we need
spring osgi or pure OSGi. Maybe you can tell us after you explore it?
Thanks
-Vincent
http://xwiki.com
http://xwiki.org
http://massol.net
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5771
days inactive
5771
days old
2 comments
2 participants
participants (2)
-
Pascal Voitot -
Vincent Massol