[forge-dev] forge on osgi

[Lincoln Baxter, III]

Right, we currently get around the Weld bootstrap/runtime service
addition/removal issue by simply restarting the entire weld container. While
this is slightly costly, tbh, it really isn't that much of a hit because the
only time people are going to be adding/removing services is when they are
installing/updating/deleting plugins - that shouldn't happen too often, so I
think yes, we can probably live without such a feature :)

I'm still interested to see what each implementation looks like before we
make a decision. Again, I'm basically useless this week since I'm at JAX,
but I'll do my best to dig in and really prototype with JBM / maven when I
get back.

This is exciting :) This is one of those features that makes or breaks a
tool!
~Lincoln

On Sat, Jun 18, 2011 at 8:53 AM, 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
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110618/5df8f0b7/attachment.html