Eclipse Community Forums: Gemini » Value of Blueprint when using Spring?

Help

Home

Home » Eclipse Projects » Gemini » Value of Blueprint when using Spring?

Show: Today's Messages :: Show Polls :: Message Navigator

Value of Blueprint when using Spring? [message #881753]

Tue, 05 June 2012 07:51

Dieter Van de Walle

Messages: 5
Registered: January 2012

Junior Member

Hi,

I have a question concerning using Blueprint and Spring.

If I am not mistaken, the value of Blueprint is in its standardized format: if you write a Blueprint application context, your bundle will deploy on all Blueprint-enabled containers.

However, many people will use Spring features in their bundle (eg. transactions), requiring some Spring bundles to be present. I am presuming it is not possible (?) for Spring to interact with beans that are instantiated via another Blueprint provider than Eclipse Gemini, so you need to use Eclipse Gemini as a Blueprint provider.

This means when using any of the Spring extended features, you are automatically tied to Eclipse Gemini as Blueprint provider right? So then what is the value of Blueprint in this situation? Does Blueprint still add some value to your bundle if you depend on Spring, and therefore also on the Eclipse Gemini Blueprint provider?

In our situation, we rely heavily on Spring extended features. As far as I can see, this means we have a hard dependency on Eclipse Gemini Blueprint.
I don't think it is possible or feasible to use another Blueprint provider in combination with the Spring features. Also, you will almost always want to refer to Blueprint instantiated beans in your extended Spring configuration (eg. instantiate a bean using Blueprint, and designate it as transactionmanager using Spring XML config), which I don't think is possible if it is not also Spring/Gemini doing the Blueprint stuff.

So unless it is possible to refer to beans instantiated with another Blueprint implementation in Spring, I don't think Blueprint has any added value in our situation?

We have now decided to use the Blueprint syntax/namespace embedded in a Spring application context. But as far as I see the only advantage this offers us is using a standardized, future-proof syntax to specify beans instead of having to learn the Spring-specific OSGI syntax.

I am very curious on your views/comments on this...

Report message to a moderator

Re: Value of Blueprint when using Spring? [message #882455 is a reply to message #881753]

Wed, 06 June 2012 13:51

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

You've got it pretty much right technically. I don't think it's possible to refer to Blueprint-defined beans from a Spring application context unless you are using a Spring-based Blueprint implementation, i.e. Gemini Blueprint.

The value of a standard for Blueprint is that it can be supported in a first class way by multiple vendors/projects. I believe IBM are making quite a lot of Blueprint at the moment. For instance, see this IBM developerWorks article. (Unfortunately, the Blueprint standard was insufficient for the chosen example and it had to use non-standard extensions, thereby somewhat detracting from the aim of using Blueprint "to gain the benefits of using Spring but in a standards-based fashion".)

Does Blueprint add some value to your bundle if you depend on Spring? I believe it may do in that Blueprint has a specification and a compliance test suite and so is less likely to display implementation bias than the precursor (Spring DM). For many people, implementation bias towards Spring is not an issue, but it may be for some.

Stepping back, the Blueprint standard still lacks quite a few significant features. These didn't make it into the recent OSGi R5 Enterprise specification and so it will probably take a few years of work before Blueprint provides parity of function with Spring DM.

Finally, I hereby invite anyone from Apache Aries Blueprint to comment in case I've missed some balancing point.

Report message to a moderator

Re: Value of Blueprint when using Spring? [message #882518 is a reply to message #882455]

Wed, 06 June 2012 16:01

Alasdair Nottingham

Messages: 1
Registered: July 2009

Junior Member

Without commenting on how Gemini and Spring work together I think there are several things that need to be considered. It is important to remember that standards rarely provide enough capability to cover all requirements (this is a good and a bad thing. It allows implementation to lead spec, but it does mean you can often do things in a proprietary way prior to it being standardised). However this does not reduce the value of standards as the implementation feeds into the standard.

Blueprint has been written with extensibility in mind. There is nothing to stop the gemini community enabling their blueprint extensions on the apache aries runtime, and vice versa.

Whether you use blueprint or not can also be down to the choice of a particular bundle author, with each bundle making use of another bundles externals via the service registry. I believe you can get into the individual beans if you make use of the BlueprintContainer service too, while I wouldn't recommend this it is possible.

Making use of standards also allows you to move container code out of the application and into the runtime. While Spring is very popular making use of it invariably ends up putting a container in a container which leads to heavier applications and increases the number of things that can go wrong. Making use of standards means the runtime provider can do all the integration which produces a better quality experience overall.

Like open source standards bodies require people with drive and the desire to get things published in a standard. Unlike Open source there is more involved that just committing the code, and multiple groups need to come to agreement, this gets harder when communities like Gemini and Aries have similar but not identical solutions to the same problem and have existing user communities to support.

Glynn and myself are both members of the OSGi alliance where the blueprint standard is evolved. If you could tell us what areas of Spring you are using we can feed this into future versions of the blueprint standard.

Thanks
Alasdair

Report message to a moderator