Re: [forge-dev] Forge 2.0 and OSGi

Let's start by explaining something about OSGi. When designing towards modularity there are two parts of OSGi that are important: 1) the classloading mechanism. Bundles (modules) declare their requirements on other packages (imports) in a manifest file. Bundles can also export packages by declaring them in the manifest so that they become available to other bundles. When the OSGi container is started the resolver will check if all declared imports are available (exported by another bundle), if not, the bundle will not start. The resolver supports versions and ranges of version, and it's possible to have several versions of the same package installed. This mechanism makes sure that you will never get classnotfoundexceptions because the resolver checks if all requirements are fulfilled, and makes sure that implementation classes can simply be hidden by not exporting them; perfect for making sure others only use your public APIs. Also note that you never write the import headers yourself (this would be a lot of work), they should be calculated by tools (bnd) instead. Exports are defined yourself however. This mechanism is similar to what JBoss Modules is doing; although it's doing a little more (which makes the resolver a little slower). Because startup speed is on the most important aspects of AS7 the resolver overhead during startup was not acceptable. I didn't see the numbers so I can judge on this, but I have seen many other very large applications that work fine (and start up A LOT quicker then Forge...) Also note that just having separate classloaders doesn't give you real modularity yet, for that we need services... 2) dynamic services A service is simply a class registered as a service; compare this to a class registered/picked up to the CDI bean manager. A service can be injected in other services, and in practice the model works very similar with other dependency injection solutions. Implementation code that should be available to others (using an API) should be published as a service; the client uses the service by it's API and simply injects the service. What makes services different from other dependency injection solutions is that they can be dynamically registered and de-registered; they can come and go during runtime. Of course this just happens randomly, there are good reasons to do this. For example, a bundle is re-installed (new version), or uninstalled. The services of this bundle will also become unavailable. Or you might pick up new configuration somewhere that should start new services for example. What happens to clients of a service that is de-registered though? In most cases you would want to de-register the client (a service itself as well) as well. In other cases you might just switch to another service that publishes the same API, or just continue work without the service. This sounds way more complex than it is; you solve these things by simply configuring this in your dependency injection framework, and everything will be handled automatically. So theoretically speaking, a Forge implementation in OSGi would require the following: -Define all Forge APIs in one or more API bundles -Implement the core as OSGi services. -A plugin is also an OSGi service, and implements a plugin interface. They are registered "whiteboard style". -A plugin injects core features by injecting OSGi services (remember, this is just DI similar as we do now) -Plugins can be dynamically installed/de-installed/reloaded by simply reloading the bundle and registering the service So yes, the architecture of Forge fits OSGi perfectly. In my opinion OSGi is not too complex. The spec is large, but that is because it's a spec that is being used over 10 years now! It supports many corner cases, and if you would have to understand each corner case you could definitely say it's complex. You don't have to however, in most cases you really only deal with the basics and they are easy. Compare it to the CDI spec. The CDI spec has many tricky corner cases as well, but most users don't even know about those corner cases, and this is fine. If you would implement your own OSGi container you would have to deal with the complexity, but by just using OSGi you don't. So should we start using OSGi? Well this is a difficult question... In my opinion we should have started that way, but it might be a little late for that. OSGi shouldn't be hacked on top of Forge, that's just going to bring more problems. Forge itself should be build in OSGi, but this will of course change things. The programming model would be very similar, but the exact APIs etc. would be considerably different. I'm not sure this is feasible at this point. If you want to see the basics of programming in OSGi (with dynamic services etc.) take a look at this talk: http://parleys.com/#st=5&id=3361&sl=0. Skip to the part where I start coding :-) Paul On Sep 25, 2012, at 2:23 , Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > ...which is pretty consistent with my point as well. It's too over-engineered (as are the arguments as to why it isn't) for low-level containers. But the need (to live in this world) is nothing a layer of abstraction can't satiate :) > > -Dan > > On Mon, Sep 24, 2012 at 6:13 PM, JFlower <fiorenzino(a)gmail.com&gt; wrote: > i remember this post: > > I've rarely in my life met a more overengineered, overcomplex spec than OSGi. Compatibility with OSGi should be an anti-requirement in any sane world. > Unfortunately we live in this world :-( > > Gavin King > > [http://in.relation.to/22155.lace] > > Fiorenzo > > PS i never used osgi in my jee apps, and i hate my eclipse when i need to restart it after a plugin installation... > > 2012/9/25 <ggastald(a)redhat.com&gt; > Hello, > > I've been done some thinking and researching for Forge 2.0 based on the last forge meeting we had and the current code in the 2.0 branch, and it seems that the architecture we're looking for is very close to OSGi architecture itself (regarding to plugability and modularity). > > I'm also afraid that we'll face the same problems that OSGi tries to solve. As my current experience with OSGi is next to minimal (and probably to better understand why and have some arguments if someone asks me about it), I would like some opinions about the advantages/disadvantages of why not having the Forge container as an OSGi compliant solution. > > Also, don't get me wrong: I am not trying to convince anyone of using OSGi into the forge core, just want to understand better why this architecture is not a viable solution so far. I know Lincoln is against using it, but I just want some arguments in case someone asks me in conferences and stuff :) > > Of course, we need to keep using CDI and annotations as well. So if it's possible to have that and at the same time the modularity (and plugability) offered by OSGi, it would be awesome. > > Looking forward for your answers ! > > Best Regards, > > -- > George Gastaldi | Senior Software Engineer > JBoss Forge Team > Red Hat > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)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://google.com/profiles/dan.j.allen > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev