wood burning stoves 2.0*
The moose likes Other Application Frameworks and the fly likes Spring DM versus JSR-291 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Spring DM versus JSR-291" Watch "Spring DM versus JSR-291" New topic
Author

Spring DM versus JSR-291

Marcel Dullaart
Ranch Hand

Joined: Nov 07, 2007
Posts: 55
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


"It would be faithless now to say farewell." (FotR, p. 419)
http://marcels-javanotes.blogspot.com/
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
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
Ranch Hand

Joined: Nov 07, 2007
Posts: 55
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
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
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
Ranch Hand

Joined: May 24, 2007
Posts: 57
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
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
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
Ranch Hand

Joined: May 24, 2007
Posts: 57
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
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
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
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
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
Ranch Hand

Joined: May 24, 2007
Posts: 57
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 ...



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
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
Augusto Sellhorn wrote:
That's what I'm doing, in my spring context I'm registering OSGi services like this ...



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
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
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 ...



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


-Mike
Pro JPA 2: Mastering the Java Persistence API
 
 
subject: Spring DM versus JSR-291
 
Similar Threads
Modular Java: comparison of OSGI with other systems and approaches and how they can be combined
OSGI bundling vs CDI bundling
module programming in spring
java plugin framework for spring
j2se 7 new keyword "module"