[forge-dev] forge on osgi

Dan Allen dan.j.allen at gmail.com
Sat Jun 18 15:02:13 EDT 2011


Paul,

Your points about OSGi are well made and definitely worth exploring.

I did leave out an important piece of information that may help bridge the
design gap.

One of the main motivators for creating JBoss Modules was to isolate the
concern of modular classloading from services, which are unnecessarily
coupled in OSGi. Of course, there is still an need for the services. That's
why the JBoss Modular Services Container [1] was created, to solve the other
half of the equation independently. JBM doesn't have a services layer
because MSC provides that :)

Together, JBoss Modules and the JBoss Modular Services Container match the
functionality that OSGi provides (you can look at it like a Venn Diagram,
with the overlap being the OSGi equivalent). JBoss even provides an OSGi
container, which as you can probably guess, is layered on top of this
foundation.

I would personally prefer OSGI because it offers a bit more (services) than
> JBM which I believe is very useful for Forge, but JBM being a JBoss project
> is a good argument to prefer this solution.


In essence, I don't think we should limit ourselves to JBM either. On the
other hand, I don't know that we have to go all the way to OSGi. And I would
say that this choice has little to do with the fact that JBM and MSC are
JBoss projects. After all, if we used OSGi, we can use JBoss OSGi, or any
other compliant container. The ownership doesn't really concern me.

The reason I'm suggesting that we use JBM and MSC is because they are the
simplest possible tool that can solve the problem (the best tool for the
job). If they aren't, for some reason, then we can shift upwards to OSGi.

Make sense?

-Dan


[1] https://github.com/jbossas/jboss-msc
[2] https://github.com/jbosgi

On Sat, Jun 18, 2011 at 08:53, Paul Bakker <paul.bakker.nl at gmail.com> wrote:

> The osgi service model makes it possible to publish services to the
> runtime. A service is just a Java interface, because services are running in
> the same VM/runtime. Services are dynamic, meaning they can come and go any
> time. From code you can ask the runtime for all services implementing a
> specific interface (other "query" metadata is possible too). With weld-osgi
> it's possble to do this completely using cdi annotations. Forge is already
> higly modular at build time because Plugins are decoupled from other
> plugins. If Plugins become services they are decoupled at runtime too. Forge
> and osgi services seems to be a perfect fit to each other.
>
> I've watched the JBoss world presentation (thanks for the links Dan!) and
> JBM looks great too. JBM doesn't have a services layer though (which is an
> explicit choice). We can live without though, since we already do now. The
> largest problem that must be solved in Forge is the classloading itself, and
> JBM does that perfectly. I would personally prefer OSGI because it offers a
> bit more (services) than JBM which I believe is very useful for Forge, but
> JBM being a JBoss project is a good argument to prefer this solution.
>
> Either solution would keep the plugin development process exactly the same
> as is. Plugin writers and users will not have to notice whatever we use.
> I'll try to work on a prototype using OSGI, even if we go for JBM it will be
> a fun experiment anyway ;-)
>
> Paul
>
> On Fri, Jun 17, 2011 at 6:39 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>> On Fri, Jun 17, 2011 at 11:59, Lincoln Baxter, III <
>> lincolnbaxter at gmail.com> wrote:
>>
>>> The reason I want to go toward JBoss Modules is because I think that we
>>> can get things working with absolutely 0 code changes required for plugin
>>> developers, and yes, also because it's a jboss project.
>>>
>>>
>> I have complete confidence that JBoss Modules [1] is the right way to go.
>> It may be young, but it has been very carefully designed by someone who has
>> crystal clear understanding of the problem. I'm not just saying that because
>> David's my respected colleague, it's backed up with proof in the form of AS
>> 7, his blogs about modularity [2] [3] and the JBoss Modules presentation.
>> I've heard the JavaDoc are very good as well. [4]
>>
>> If you haven't yet, I strongly recommend all of you to watch the
>> presentation on JBoss Modules from JUDCon [5], which was given by David by
>> his proxy, Jason Greene. It gives an overview of JBoss Modules, but more
>> importantly it explains how it relates to OSGi and Maven.
>>
>> JBoss Modules truly is a good fit. Plus, Forge could really help get the
>> word out about the benefit of modularity in general.
>>
>> -Dan
>>
>> [1] https://github.com/jbossas/jboss-modules
>> [2] http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
>> [3]
>> http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1
>> [4]
>> https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jboss/modules/ConcurrentClassLoader.java
>> [5] http://vimeo.com/24776447
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://www.google.com/profiles/dan.j.allen#about
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>


-- 
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110618/81367e2b/attachment.html 


More information about the forge-dev mailing list