OSGi possible without Spring?

[Marco Ehrentreich]

Hi Craig,

you've talked about OSGi with Spring and the OSGi API itself in other posts. Does your book expect to use OSGi together with Spring or does it also explain how to build applications with pure OSGi? Or does it in your opinion even make sense to use OSGi without the benefits of the Spring framework?

Marco

[Craig Walls]

Marco Ehrentreich wrote:you've talked about OSGi with Spring and the OSGi API itself in other posts. Does your book expect to use OSGi together with Spring or does it also explain how to build applications with pure OSGi? Or does it in your opinion even make sense to use OSGi without the benefits of the Spring framework?

I spend the first few chapters "Spring-free". It is quite possible to use OSGi without Spring and...surprise, surprise...it's not *that* hard.

But I don't present pure OSGi because I think it's a great way to develop OSGi-based apps. I present it so that the reader will understand what's going on under the covers of Spring-DM and to be able to work with native OSGi if the need arises.

In response to your last question: I personally wouldn't choose to do much OSGi without Spring-DM (or the OSGi R4.2 Blueprint Services, which is just a formal spec version of Spring-DM). But that's just a choice I make. There are other declarative OSGi models such as OSGi's DS (Declarative Services) and Apache Felix's iPOJO. Both of these, like Spring-DM, eliminate much of the need to work with the native OSGi API.

What's great about all of these options is that they all interoperate very well. A service published by Spring-DM can be consumed by native OSGi. A native OSGi service can be consumed by iPOJO. An iPOJO service can be consumed by Spring-DM. Once a service is published in the OSGi service registry, it's not all that important as to how it got there.

[Marco Ehrentreich]

On the one hand it sounds quite reasonable to leverage the advantages of a more powerful framework like Spring. On the other hand I'm unsure if this approach adds too much overhead for smaller applications.

Of course it doesn't make any sense if an application is too small to even have modules, but would you recommend using OSGi and Swing for smaller applications? Or does it pay off only for bigger projects like enterprise applications?

Marco

[Ulf Dittmer]

A module can be quite small, though. A while ago I dabbled around with adding plugins to a Java desktop application (see Adding Plugins to a Java Application for a writeup), and even though that was kind of a smallish application, I think these days I'd use OSGi for that.

[Marco Ehrentreich]

Thanks for the link, Ulf. I'm going to have a look at it...

I think you're right. A modular application design is definetly useful for smaller applications, too. Because I'm lacking some more experience with Spring, I'm just unsure if it would be overkill to use OSGi AND Spring or just an OSGi framework like Apache Felix. I know, the whole Spring framework offers a lot more than just OSGi support, but I don't know "how much of Spring" you have to use in order to have Spring based OSGi support.

Marco

[Craig Walls]

Marco Ehrentreich wrote:I think you're right. A modular application design is definetly useful for smaller applications, too. Because I'm lacking some more experience with Spring, I'm just unsure if it would be overkill to use OSGi AND Spring or just an OSGi framework like Apache Felix. I know, the whole Spring framework offers a lot more than just OSGi support, but I don't know "how much of Spring" you have to use in order to have Spring based OSGi support.

It's a game time decision. I believe that the vast majority of applications could benefit from OSGi. But there are some where those benefits are diminished. Same with adding Spring-DM. Most OSGi applications will benefit from the declarative model offered by Spring-DM...but for simpler cases, maybe it's overkill and a simple BundleActivator will suffice. I'm not going to tell you when it's a good idea or not...you'll have to sort that out for yourself on your own projects.