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.
Related
I'm trying to get comfortable in the vast ecosystem of enterprise OSGi programming, but I find it very difficult to get an overview of how this technology stack is put together, which technologies build upon one another, which technologies solve what task, and how they all fit in the limited terminology I have managed to understand so far.
For example: What is the relation between Apache Felix, Equinox, Karaf, Jira OSGi, Spring DM, Aries Blueprint, Gemini Blueprint, iPOJO, Camel etc. etc...
I know Equinox is based on Felix, and that the Blueprint variants and iPOJO are somewhat related to component management, but what about Declarative Services? Is DS an alternative to Blueprint, or is Blueprint an implementation of Declarative Services?
In general, I am heavily confused, and I really need a simple overview of how common OSGi technologies in general are related.
Does anyone know of there exists such an overview - perhaps graphical - of the OSGi ecosystem?
Best regards.
I don't know of a graphical representation. I can break down the few specific things you have mentioned in your post:
An "OSGi Framework" is an implementation of the core OSGi specification. It would have to implement the concept of bundles, installing and resolving bundles, lifecycle, services and so on.
Apache Felix is an OSGi Framework implementation.
Equinox is also an OSGi Framework implementation. It is not "based on" Apache Felix but it does borrow a small amount of code from it. Equinox is the implementation of OSGi used in Eclipse etc.
Karaf is essentially an application server product. It uses Felix as its core OSGi Framework implementation, and then adds a lot of extra features on the top.
Jira OSGi: don't know. I believe Jira is internally implemented with OSGi but I don't know any of the details.
Spring DM is an obsolete/dead project. It was a way of splitting up a Spring bean graph into a modular application, using OSGi.
Blueprint is a specification published by the OSGi Alliance. It is one of the Compendium specifications, i.e. add-ons that are not required in the Core. Blueprint was inspired by Spring-DM and it standardises the idea of wiring together beans within and between bundles.
Gemini Blueprint is an implementation of the Blueprint specification. Gemini started with the Spring-DM code and evolved it to comply with the (then) new specification.
Aries Blueprint is also an implementation of Blueprint. It is "clean-room", i.e. implemented from scratch against the specification rather than evolved from older Spring code.
Declarative Services is an OSGi specification from the Compendium. It is an alternative way to define components and to wire them together using services across bundles. Many experienced OSGi developers – including me – consider Declarative Services to be FAR superior to Blueprint. I can elaborate more on the reasons for that if you like.
iPOJO is yet another different way to define components and wire them together. It does not conform to any OSGi specification.
Camel is an integration library, mostly used for messaging applications. It doesn't have much to do with OSGi except that it can run under OSGi.
I hope this helps.
Imagine you want to have a highly modular web application in Java. Components are already using Spring framework also. Some components cover only pure Logic and some others also come with some presentation GUIs in HTML. The application is not Portlet compatible but we need to have dynamic menu which promotes the list of installed modules and links to the pages or REST APIs. Since it’s Java, using OSGI is recommended but I got too much confused with the recent features in OSGI (introduced past few years) and I have few questions:
Now OSGI is not only Module Management System but also IoC Container! It almost contains equivalent annotations for many of Spring IoC features. So How we can use Spring enabled modules inside OSGI? Can we eliminate Spring for our new designs and completely rely on OSGI? Or for dependency Injection within the modules we can use Spring and for Dependency injection over the Modules we can use OSGI?
For real-life large scale applications we have two options: Using Embedded Felix within application Container (e.g. Tomcat) or Using OSGI Bundle of Application Container (Jetty or Tomcat) within KARAF. Which approach is better? Which one is more scalable?
Researching OSGi can get confusing because there are 15 years of articles and examples out there - a lot of which are valid but may be out of date.
You could consider removing Spring if it was just used as an IoC container. OSGi DS provides #Component and #Reference annotations (like spring Autowire) if DS is enabled in your OSGi container. The new OSGi enroute project has some modern examples of performing IoC and providing REST services.
Replacing more of the features might be more work. Running the latest Spring in OSGi may not work due to the classloader differences in OSGi and the spring projects move away from OSGi.
OSGi is no IoC container at all. There are some technologies for injection support that run on OSGi though. The most important are declarative services and blueprint. Spring is not really supported. There is some Spring DM support but this code is not maintained for ages.
So you should use one of the two supported IoC containers above. For aries blueprint I have written support for CDI annotations using the maven-blueprint-plugin. This may be your best bet to convert the application. I recommend to first convert your spring application to use only CDI annotations and only then start the OSGi migration. Such a migration is not easy. Make sure you get some good coaching and consulting.
Embedded Felix on a servlet container is good if most of you application is non OSGi and you just want to use bundles for a very small part. Karaf is better if you want to write your whole application for OSGi.
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.
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.
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.