Skip to main content

CDI vs. Spring Framework Core

Another question I got in my Spring Framework training is: is it worthwhile to switch from Spring Framework 3.x to CDI with JBoss Weld or Apache OpenWebBeans implementation?

After googling around I found some good articles and blogs about this topic. These two articles are the best in my opinion:
Luckily I had a chance to take a CDI course intensively for two days to be able to see what we actually could do with CDI. After doing two days intensive course of CDI I can sum up this topic as following:
  • CDI takes a lot of good idea of Spring Framework, this is for sure.
  • Anything you can do with CDI (I used JBoss Weld in the course I followed) is not new and you can have those stuffs in Spring Framework as well.
  • In CDI 1.0 (JEE 6) there is still a lot of things which is not supported natively such as "scanning of classes and packages" to turn on the dependency injection. Sure you can use CDI portable extensions to support such a functionality but the problem with those extensions is just like Eclipse plugins: you never know whether all of the plugins can work smoothly together if they are not written by one person or one vendor.
Additionally to the articles and blogs above I found following extensions for Spring Framework to support following CDI mechanism:
(1) Events with @Observes: take a look at this Open Source project which extends Spring capability: spring-event-annotations.

 (2) Decorator with @Decorator and @Delegate: take a look at this blog and Open Source project: JSR-299 CDI Decorators for Spring beans.

 (3) Interceptor with @Interceptor, @InterceptorBinding, @AroundInvoke and @Nonbinding: take a look at this article: JSR-299 CDI Interceptors for Spring Beans.

 (4) Custom bean scope: take a look at this article: Custom scopes in CDI 1.0 and Spring 3.1.

 (5) Type-safe injection: take a look at this blog: Type-safe dependency injection in Spring 3 IoC-Container.

At the end I have to admit that you won't miss anything if you are using Spring Framework. It is definitely more mature than any other Context and Dependency Injection containers available on the market. So if you ask me whether it is worthwhile to switch from Spring Framework Core to CDI implementation like JBoss Weld I would say: no.There is also no economically reasons to switch to CDI implementation if you are already use Spring Framework. Try explain to your management that you want to switch to CDI just because it is standard, no other advantages and also with less functionality and maturity. Surely you should use the standard Annotations within Spring Framework, so instead of @Autowired you should use @Inject for example. In some ways I see Spring Framework Core as "the" reference implementation of CDI specification.

Cheers,
Lofi.
Labels:

Comments

rmannibucau said…
Hi

that's just a small part of the issue but basically for an existing app you are probably right.

The main point is using standard annotations in spring doesn't mean you'll get standard behavior (that's not the case at all) so it is probably better to not use standard annotations finally.
1:02 AM
lofidewanto said…
True with the behaviour but if you only use the really standard one like @Inject, @Named they behave just the same like what CDI container implementation does.

Lofi.
12:52 PM
Post a Comment

Popular posts from this blog

Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?

Last year we saw the launch of a new Web programming language Dart - Structured Web Programming from Google. A very interesting approach to support web application development. Not so long after Go, Groovy, Ruby, Scala, << name your DSL here >> ; we see Dart. Is it a good thing to have at least one programming language to solve one problem? The answer is, like we already know, it depends. Some important backgrounds you should know about the multi programming language paradigm are following: 1. You can read Martin Fowler article about language oriented programming with language workbenches which enables you to write small programming languages easily. In this article I see everyone writing their small languages, everywhere. In this concept we see DSL (Domain Specific Language) as the future of our programming activities. Source: http://martinfowler.com/articles/languageWorkbench.html 2. Neal Ford talked about Polyglot Programming, combining multiple programming language...
32 comments
Read more

Software Development Macro and Micro Process

If you think that in year 2012 all companies which produce software and IT divisions in our world have already their optimized software development process, you are wrong. It seems that we - software architects, software developers or whatever your title is - still need to optimize the software development process in many software companies and IT divisions. So what do you do if you enter a software company or IT division and you see following things: 1. There is a perfect project management process to handle all those development of software but it is a pure project management without a context to software development. So basically you only take care of cost, time, budget and quality factors. In the software development you still use the old fashioned waterfall process. 2. From the tooling point of view: you have a project management planning and controlling tool but you are still in the beginning of Wiki (almost no collaboration tool) and you don't use issues tracking sy...
20 comments
Read more

Creating Spring Bean dynamically in the Runtime

In my training someone asked me whether it is possible to create an object (a Spring Bean) dynamically so you can choose which implementation you want to have  in the runtime . So at the compile time you don't know what object actually should be created yet. The application should decide what object to be created based on a property file . 1. We create an annotation so we can mark the method which should be able to create the object dynamically: ... package your.package; ... @Retention(RetentionPolicy.RUNTIME) public @interface InjectDynamicObject { } ... 2. Use the new created annotation in your method which should be able to create the object dynamically: ... @Named("customerBo") public class CustomerBoImpl implements CustomerBo { ...     @Override   @InjectDynamicObject   public Customer getDynamicCustomer() {         return this.dynamicCustomer; } ... 3. Write an aspect with Pointcut a...
10 comments
Read more