What is the status of the current developments around Spring and OSGi?
It looks like things have gotten a bit quiet lately.
The latest version of the doc at (http://docs.spring.io/osgi/) is from 2009.
I see some announcements that Spring DM has become Eclipse Gemini Blueprint (http://www.eclipse.org/gemini/blueprint/documentation/migration/). But also there, the latest release is from August 2012.
Is Spring and OSGi a dead path? If so, what other options are there to make a spring application modular (e.g. allow deployment, starting, stopping & updating of a module within a running JVM)?
Thanks
I agre that spring on OSGi is a dead end. There does not seem to be any real drive in it since springsource abandoned OSGi.
There are some alternatives though. The most stable and complete one is Apache Aries at the moment. It provides blueprint support which is similar to spring xml and some extensions like jpa container managed transactions. Be aware though that aries still contains much less functionality then spring. So for example annotation support is very limited.
Alternatives to Aries blueprint are Declarative Services and pax CDI. Declarative services is very small footprint and quite stable and has great supports for the dynamics of OSGi. On the other hand it is even more limited than blueprint. So for example there is no special jpa support at all.
PAX CDI aims to provide Java EE on OSGi using Open Webbeans or Weld + some extensions like Deltaspike. Together it would provide similar comfort like Java EE 6. Unfortunately it is not completely finished so at the moment I would not yet consider it ready for production use.
Gemini Blueprint is still active, right now gemini blueprint upgraded to support R5 and M2 is available in the eclipse nexus.
Related
long time ago I have already been working with Spring in an OSGI context. At this time there was a subproject called Spring Dynamic Modules being the first address for an integration of the two frameworks.
Coming back to the scene some years later the situation is not clear anymore (for me). Spring Dynamic Modules has migrated to Blueprint and there are 2 major implementations Aries and Gemini where the first one seems to be more in competition with Spring than complementing it and the latter seems to be small and with very rare release cycles.
The official Spring page has no documentation at all any more concerning OSGI.
So can anyone with a better standing / know how in Spring help and tell me what's currently (11/2014) the "official" or preferred way to integrate Spring applications into an OSGI environment?
Many thanks & best regards
Rabe
Official according to whom? There is nobody qualified to give an "official" answer on this, there are only common practices.
As you note, the Eclipse Gemini implementation of Blueprint is abandonware. The Apache Aries implementation is a live project though, and it is not so much in competition with Spring as a clean-room implementation of the Blueprint specification without reference to the old Spring source code.
As such, I recommend migrating to the Aries Blueprint implementation as the most practical and sensible way forwards.
Spring does not officially support OSGi nowadays. Spring EBR repository was closed (I guess as they had said they would close it) and some company took over the content in Virgo EBR repo. I do not know if it is still alive.
If you have a choice, do not use Spring within OSGi. It is a great technology, but it was designed to work well in monoholitic systems. There is a good blog post why not to use Spring, blueprint and similar technologies within OSGi: http://blog.osgi.org/2014/09/how-should-i-use-guicespringblueprint.html
I'm experimenting with OSGI and CDI. I want to register my OSGI services using CDI annotations and also retrieve the registered OSGI services using CDI.
I have found the following: https://github.com/mathieuancelin/weld-osgi, it seems like it is integrated into weld-core. But when I depenend on the weld-core 1.2.0.Beta1 or 2.0.0.Final version, I do not find any of the annotations specified in the documentation on https://github.com/mathieuancelin/weld-osgi.
It this weld-osgi the way to go when you want to use OSGI with CDI? Or should I use spring? (I prefer weld because my AS is currently jboss EAP 6.1)
In which dependency can I find the annotations specified in the documentation?
Thanks!
Currently I do not advice using CDI to work with OSGi services. The Weld-OSGi library is still very experimental and will most likely change when the OSGi-CDI specification is released.
At this moment a new specification, OSGi-CDI (RFC 193) is being written in the Enterprise OSGi expert group (I'm one of the members writing this spec). OSGi-CDI is scheduled to be part of Enterprise OSGi R6 early next year. Unfortunately, it's too early to start using this yet, the reference implementation is far from finished. Some more details about the upcoming specification can be found in a presentation I gave at EclipseCon this year: https://speakerdeck.com/paulbakker/rfc-193-osgi-cdi
I strongly advice to use one of the other dependency injection solutions available for OSGi services, preferably either Apache Felix Dependency Manager or Dynamic Services. Because both of these libraries are built directly on the OSGi service API, you don't have to drag in other dependencies. The programming model is obviously different than CDI, but the concepts are very similar, so it should be easy to pick up.
Do not use Spring either because it doesn't really fit OSGi very well (although it can work).
I haven't worked on it, and I know little about weld-osgi, but you should be using it if you want OSGi and CDI to play nicely. I'm pretty sure they're separate jars, you'll need to add the weld-osgi dependency to your project.
Is the any way to perform integration CQ5 platform with Spring framework?
I would like to use Spring IoC capabilities to make my code more clear and efficient.
UPDATE
Hello againg, seems that I found solution.
Guys here developed Slice framework that really redices amound of code and made CQ5 development easier.
You probably want to check out Eclipse Gemini Blueprint, or it's original incarnation Spring Dynamic Modules. The Blueprint project basically gives you an easy way to create Spring enabled bundles in an OSGi environment.
As shsteimer mentions, Spring distributions before 3.2.0 were OSGi bundles, so could be dropped into an OSGi environment and you could probably use them directly. Spring 3.2.0 bundles and above are now available through the SpringSource ERB. However, Blueprint gets around or helps with some of the boilerplate OSGi stuff that you would otherwise have to do.
On a past project, I was able to get Spring JDBC working inside of CQ (to support some legacy code so we didn't have to re-write it). My memory is that the spring jar files already come "OSGI-ified" and so it was just a matter of figuring out all the layers of dependency needed for JDBC to work inside of CQ, and adding all the jars to the repository in an /apps/myApp/install folder.
Long story short, I'm not sure about IoC, but you might check to see if it's already packaged as an OSGI version which you can simply use without too much hassle.
I am a little bit confused about Blueprint and Spring DM:
From what I think is true:
Spring DM is a framework defined by Spring Source
Blueprint is a framework defined by the OSGi Alliance
Blueprint has "taken" many of it's ideas from Spring DM
No?
Can we expect that those two frameworks become one in the future (merge)? If not, which one will be the most future-proof?
OSGi 4.2 introduces the Blueprint Service specification based on
Spring Dynamic Modules project for which Spring DM (2.x) is the
Reference Implementation (RI).
In short: Blueprint is a specification, Spring DM is an implementation of Blueprint API
Blueprint was developed in the OSGi Alliance under the lead of SpringSource/Interface21.
However, if you're looking for a way to leverage OSGi use Declarative Services (DS) with annotations between bundles (services). In my experience, you do not really need the wiring XML when you make small cohesive bundles. DS is much better in working with services than Blueprint/Spring DM since they tend to to want to "hide" the dynamicity while DS just makes it trivial to use.
My understanding is that SpringDM is a dead project. Check the GA and release dates. So although it contributed much to the development of the specification in the end it had a bad approach to classloaders. Apache-Aries is a strong blueprint implementation. Note that use of blueprint does not preclude use of spring. I would suggest Karaf as a robust platform that can use either Eclipse Equinox or Apache Felix for the OSGI engine. I like blueprint versus DS if you are developing at the application level where your services may be used by other teams or organizations within your enterprise, or extended by your customers. I think blueprint is also a better fit for traditional enterprise computing environments. But DS or Ipojo may be more appropriate depending on your particular target environment.
In addition to what Dmytro Pishchukhin answered, it should be noted that the Spring DM project is somewhat a dead project, as DM 2 never reached a "release" version.
Instead it was contributed to the Eclipse foundation where it mutated into the Gemini Blueprint project.
In the introduction of the Gemini Blueprint documentation they explain clearly the difference :
http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html
I reproduce here :
Chapter 1. Spring Dynamic Modules becomes Eclipse Gemini Blueprint
In late 2009, as a member of the Gemini project proposal, SpringSource contributed Spring Dynamic Modules (also known as Spring OSGi) project to the Eclipse Foundation. Spring DM v2 code base has been moved to Eclipse.org along with its issue tracker and forum. The project became dual licensed under Apache License and EPL.
While the name has changed, the code and its functionality remained the same. Existing Spring DM applications can be easily migrated to Eclipse Gemini Blueprint as mentioned in the migration guide.
What's the current situation with integrating Guice and OSGi? I.e. exposing OSGi services from Guice, injecting them, etc.
Peaberry's main page mentions "The Guice trunk (which will become 2.0)", but 1.2 seems up-to-date, since it fixes http://code.google.com/p/peaberry/issues/detail?id=58. Its author has switched Sisu, but it doesn't seem to be released yet. Any others?
The integration of Guice 3.0 and Peaberry 1.2 currently is working like expected. Just the page seems to be a little outdated sind the snippet mentioned above refers to the Guice 2.0 trunk which has been superseded.
The Bug your referencing is fixed for the 1.2 Peaberry release when you look at the repository history here.
It's true that Sisu is currently developed and it solves (at least how I interpret it) some additional problems that are currently existing with Guice + Peaberry + OSGi (e.g. automatic component scanning and discovery) but it isn't ready yet.
In my opinion Peaberry solves the same integration cases of DI and OSGi that are also solved by Spring Dynamic Modules (now Eclipse Gemini Blueprint) and is therefore very useful. Also I don't think necessarily that the Peaberry project will be abandoned in favor of sisu.
If all you stay true to the OSGi idea of developing independent bundles that are wired through services but you want to use DI inside them, Peaberry currently offers everything you need for that.
The only problem I'm currently facing with that combination is that the official guice-servlet module doesn't seem to play with the OSGi HttpService by default.