I have a Spring3 application which takes about 3 minutes to load a big domain model on startup... this is fine when the application is deployed to a production environment every once in a while but its a massive pain when making development changes due to the stopping/starting of the application.
I've done a bit of investigation and I like the idea of separating my application in modules using OSGi so that I can deploy only the parts of my application which are changing (e.g. No need to deploy the Domain Model when I'm making changes to the Persistence layer); However I've found the barrier to entry for OSGi to be quite high.
Is it possible to use both Blueprint to inject the services provided between modules (e.g to expose implementations of the domain model to my web tier) and to continue to use the Spring framework (not Spring Dynamic Modules) inside each of my modules?
You can not mix blueprint and spring. They are two separate technologies that are similar but incompatible.
I would also not recommend using spring dm in OSGi. While it works for some simple cases it has a horrible classloading model that leads to massive problems in OSGi. See this article from Guillaume Nodet. Besides that spring dm was abandoned by springsource. There are not even bug fixes since ages.
Spring Gemini is also practically abandoned. Springsource donated it to eclipse and then ceased to really work on it.
So if you want to go this step to OSGi you will have to switch to aries blueprint or to declarative services. So do not underestimate the effort.
Related
How to integrate the spring boot project generated by swagger with OSGi and deploy it in Apache karaf?
How should I write my pom.xml and how to modify the startup class. If there is something not detailed, I will add it. Thank you!
You don't. It's not strictly impossible but it would be a lot of work and struggle and you will not get any benefits out of it.
If you want SpringBoot - stick to that. You will sacrifice modularity, strong encapsulation, enforced clean architecture and bunch of other architectural thing that will matter a lot in the long run. But you will gain something that is easy to work with in the beginning and tons of code to copy/paste.
If you are playing the long game - I'd recommend to forget about SpringBoot and learn how to build modular OSGi applications. Recent version allow you to use popular technologies like JAX-RS and CDI. You can probably use one of the Swagger's JAX-RS generators and then convert the outcome to proper modular code. It may even be that there is a generator that generates OSGi JAX-RS code already.
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.
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
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.