I will prefer to commit for JBoss with Tomcat rather then OSGi which should stay at the middleware services level

Sorry for the misunderstanding! It’s also often unclear what people mean by the “OSGi programming model.” I’m sure I have contributed to the lack of clarity here.

What I mean by it is using the OSGi service model to create applications by whatever means are available. I don’t usually distinguish among the various means available to create, register, and consume OSGi services, since what I focus on are the services themselves and their interactions.

This is perhaps a subtle difference in how I would make recommendations, but I think that we are more in agreement than I first thought. I would not recommend against someone using the OSGi APIs, if they really wanted to do so I think it’s ok. I would definitely recommend that someone use something like the Blueprint service, OSGi DS, iPOJO, or Peaberry instead of the native APIs, but if someone really wanted to use them (and was aware of all the alternatives) I wouldn’t try to stop them. It’s a small difference but perhaps that is how the misinterpretation occurred.

Thanks,

Eric

Its probably both Eric. You misinterpreted what I was previously talking about. I was probably a bit unclear.

Again, I do believe OSGi APIs should be reserved for system programmers. I *know* the benefits of something like OSGi can be abstracted away from application developers and brought to existing component models like Spring, EJB, Seam, or any other component model. It just seemed from the OSGi Remoting thread that some of you were pushing OSGi as an application-consumable API.

Dependency management, classloading, hot-deployment are all great things Eric. Are all core features that at least JBoss users are used to.

Now I’m confused about your objection. On TSS article I posted, I had understood your comment to be that app developers should never use OSGi at all, that it is something reserved for system programmers such as yourself.

This post seems to be arguing in favor of application developers using the OSGi programming model.

The only difference I see now is that you appear to be qualifying your earlier statement with something like “as long as you use some kind of inversion of control abstraction, the OSGi programming model is ok for application developers.”

Is that right?

BTW check my OSGi blog for a recent entry on the tooling issue, which is closely related to this debate: http://modualrit.blogspot.com/2009/04/tooling-related-challenges-for-osgi-eeg.html

Eric

You should see some of the deployment abstractions we have in JBoss 5. For example, if you want to augment a servlet deployment you can plug a deployer in that gets notified of servlet metadata, changes/adds to it. All before the web archive gets deployed. An example of this would be Seam or JAX-RS looking for annotated component and adding new servlets or filters to the deployment. If we could get their in OSGi land, you’d have the ability to extend and expand the capabilities of a third party container. See where I’m getting at?

I believe that your second paragraph about what you “hoped OSGi would become” describes quite well what OSGi already is and has been for some time.

You may say that I’m an OSGi evangelist but I’m one that moved from EJB 1.1 to EJB 2.0, Spring and then to OSGI. And for the moment I do not what to get back, not that they are exclusive. So, do not take that away from me. let me have the option. If I wanna use it, fine. Is MY decision.

But it’s a good point that many people don’t think about this issue too much. We get all excited with the features that OSGi provides but don’t consider the consequences of compile time dependencies on the framework.

— Patrick