Spring DM versus JSR-291

[Marcel Dullaart]

Hi folks,

Congrats with the release of your book about OSGi.

What do you think about the Spring DM implementation versus the JSR-291 specification?
Follow the JCP standard or use alternative API's such as Spring DM?

Kind regards,
Marcel Dullaart

[Richard S. Hall]

Marcel Dullaart wrote:Congrats with the release of your book about OSGi.

Thanks.

Marcel Dullaart wrote:What do you think about the Spring DM implementation versus the JSR-291 specification?
Follow the JCP standard or use alternative API's such as Spring DM?

JSR 291 is actually OSGi R4.1 (I believe or R4.0.1, whichever). Spring DM is an approach for integrating the Spring bean model with OSGi, so in this case you don't have to choose between these two, since Spring DM should work with JSR 291. The real choice now is between Spring DM and OSGi Blueprint, where the latter is the OSGi standardized version of Spring DM. Here, though, it probably makes sense to go with Blueprint, since there are already multiple implementations of it.

[Marcel Dullaart]

Thanks for the quick response and the clarification.
I was under the impression that Spring DM came with extensions not covered by the spec, that originated my question.
Me, as an architect, usually prefer to follow standards, striving to make the actual business code vendor independent as much as can be.

Kind regards,
Marcel Dullaart

PS guess I have to catch up on the subject again

[Richard S. Hall]

Marcel Dullaart wrote:
I was under the impression that Spring DM came with extensions not covered by the spec, that originated my question.
Me, as an architect, usually prefer to follow standards, striving to make the actual business code vendor independent as much as can be.

Yeah, so in that case, you'd definitely want to look into Blueprint if you want to stick with standards and you are interested in Spring DM.

I think it would be a mistake, though, to think that you should only use standardized stuff on top of OSGi. OSGi technology provides a good foundation for creating reusable modules. Not every useful module needs to be (or can be) standardized.

[Augusto Sellhorn]

You know, I really get confused between Spring DM and Blueprint.

In karaf (more specifically Apache servicemix) bundles have 3 states.

1. OSGi bundle state (ex: Active)
2. Blueprint state (I've only seen this either empty or Created)
3. Spring state (I've seen Active and Failed)

It gets a bit confusing when things are OK in the bundle state (Active) but the Spring state is (failed).

The only time I'm aware I'm using blueprint is when extending shell commands (OSGI-INF/blueprint), I'm assuming every time I have a spring context (META-INF/spring)in OSGi that's Spring DM but you seem to imply Blueprint has integration with Spring ...

[Richard S. Hall]

Augusto Sellhorn wrote:You know, I really get confused between Spring DM and Blueprint.

In karaf (more specifically Apache servicemix) bundles have 3 states.

1. OSGi bundle state (ex: Active)
2. Blueprint state (I've only seen this either empty or Created)
3. Spring state (I've seen Active and Failed)

It gets a bit confusing when things are OK in the bundle state (Active) but the Spring state is (failed).

The only time I'm aware I'm using blueprint is when extending shell commands (OSGI-INF/blueprint), I'm assuming every time I have a spring context (META-INF/spring)in OSGi that's Spring DM but you seem to imply Blueprint has integration with Spring ...

I don't really know, since I don't really work with Karaf, Blueprint, or Spring. But I would assume that these are layered states. For example, if a bundle is ACTIVE, it means its code dependencies are satisfied and someone wants the components inside to be created if possible. But just because someone wants the contained components to be created, doesn't mean they can be. If the components depend on other services that are not yet available, then the Blueprint state might not be valid yet until the needed services are available. As for the Spring state, I have no idea what that is, but I guess it would be related to the internal configuration state of the Spring beans that compose the component.

[Augusto Sellhorn]

Yeah, it's a bit confusing, although I think that's more of a karaf thing.

I do with that OSGi had a state that differentiated between "runnable" bundles (have an Activator) vs API bundles (with no activator). It's kind of weird that you can "start" bundles that don't really "start".

[Richard S. Hall]

Augusto Sellhorn wrote:The only time I'm aware I'm using blueprint is when extending shell commands (OSGI-INF/blueprint), I'm assuming every time I have a spring context (META-INF/spring)in OSGi that's Spring DM but you seem to imply Blueprint has integration with Spring ...

It seems you are getting confused between Spring and Spring DM. Spring != Spring DM.

It is more accurate to say Spring DM is basically equivalent to Blueprint. Spring DM provided the starting point for creating the OSGi Blueprint spec, so they are not identical, but very similar.

What is Blueprint (or Spring DM, for that matter)? It integrates the Spring bean model with the OSGi platform. It allows you to package Spring beans inside bundles and for Spring beans to publish their interfaces into the OSGi service registry and to be injected with services from the OSGi service registry. That's pretty much it.

[Richard S. Hall]

Augusto Sellhorn wrote:Yeah, it's a bit confusing, although I think that's more of a karaf thing.

I do with that OSGi had a state that differentiated between "runnable" bundles (have an Activator) vs API bundles (with no activator). It's kind of weird that you can "start" bundles that don't really "start".

They do, it is RESOLVED. You don't have to start a bundle to load classes from it. However, there is no harm or cost in starting a bundle without an activator. Further, this is leveraged in the OSGi extender pattern to indicate that another bundle should do something on the target bundle's behalf. This is how Declarative Services spec, Blueprint spec, Web Applications spec, iPOJO, etc. all allow you to manage when the features contained in a bundle should actually be made available (i.e., you can turn them "on" by activating the bundle and turn them "off" by stopping it) even though it doesn't have an activator.

[Augusto Sellhorn]

Richard S. Hall wrote:

Augusto Sellhorn wrote:The only time I'm aware I'm using blueprint is when extending shell commands (OSGI-INF/blueprint), I'm assuming every time I have a spring context (META-INF/spring)in OSGi that's Spring DM but you seem to imply Blueprint has integration with Spring ...

It seems you are getting confused between Spring and Spring DM. Spring != Spring DM.

It is more accurate to say Spring DM is basically equivalent to Blueprint. Spring DM provided the starting point for creating the OSGi Blueprint spec, so they are not identical, but very similar.

What is Blueprint (or Spring DM, for that matter)? It integrates the Spring bean model with the OSGi platform. It allows you to package Spring beans inside bundles and for Spring beans to publish their interfaces into the OSGi service registry and to be injected with services from the OSGi service registry. That's pretty much it.

That's what I'm doing, in my spring context I'm registering OSGi services like this ...

    <bean id="SimpleRunnable" class="foo.bar.osgi.simpleservice.SimpleRunnable">
    </bean>

    <osgi:service ref="SimpleRunnable" interface="java.lang.Runnable">
        <osgi:service-properties>
            <entry key="type" value="test"/>
        </osgi:service-properties>
    </osgi:service>

Is this Spring DM or Blueprint? I'm thinking it's Spring DM, since the state of this bundle under the "spring" column shows as failed if there's an error in it.

[Richard S. Hall]

Augusto Sellhorn wrote:
That's what I'm doing, in my spring context I'm registering OSGi services like this ...

    <bean id="SimpleRunnable" class="foo.bar.osgi.simpleservice.SimpleRunnable">
    </bean>

    <osgi:service ref="SimpleRunnable" interface="java.lang.Runnable">
        <osgi:service-properties>
            <entry key="type" value="test"/>
        </osgi:service-properties>
    </osgi:service>

Is this Spring DM or Blueprint? I'm thinking it's Spring DM, since the state of this bundle under the "spring" column shows as failed if there's an error in it.

Not sure, but it looks very similar to Blueprint. I don't use and am not involved with either.

[Mike Keith]

Augusto Sellhorn wrote:

Richard S. Hall wrote:

Augusto Sellhorn wrote:The only time I'm aware I'm using blueprint is when extending shell commands (OSGI-INF/blueprint), I'm assuming every time I have a spring context (META-INF/spring)in OSGi that's Spring DM but you seem to imply Blueprint has integration with Spring ...

It seems you are getting confused between Spring and Spring DM. Spring != Spring DM.

It is more accurate to say Spring DM is basically equivalent to Blueprint. Spring DM provided the starting point for creating the OSGi Blueprint spec, so they are not identical, but very similar.

What is Blueprint (or Spring DM, for that matter)? It integrates the Spring bean model with the OSGi platform. It allows you to package Spring beans inside bundles and for Spring beans to publish their interfaces into the OSGi service registry and to be injected with services from the OSGi service registry. That's pretty much it.

That's what I'm doing, in my spring context I'm registering OSGi services like this ...

    <bean id="SimpleRunnable" class="foo.bar.osgi.simpleservice.SimpleRunnable">
    </bean>

    <osgi:service ref="SimpleRunnable" interface="java.lang.Runnable">
        <osgi:service-properties>
            <entry key="type" value="test"/>
        </osgi:service-properties>
    </osgi:service>

Is this Spring DM or Blueprint? I'm thinking it's Spring DM, since the state of this bundle under the "spring" column shows as failed if there's an error in it.

It could be either since the elements are the same (but is likely Spring DM since Blueprint namespaces are not typically named "osgi"). Note that Spring DM no longer exists, really, since it was donated to Eclipse in the form of the Gemini Blueprint project. See the statement made by SpringSource for more details.

-Mike
Gemini Project Lead