cdi

Autowiring is a particular kind of wiring, where injecting dependencies is not explicit but actually managed implicitly by the container. This article tries to provide some relevant info regarding disadvantages of using autowiring. Although Spring is taken as an example, the same reasoning can apply to JavaEE’s Context and Dependency Injection.

Let’s face it, there are two kinds of developers: those that favor Spring autowiring because it alleviates them from writing XML (even though you can do autowiring with XML) and those that see autowiring as something risky. I must admit I’m of the second brand. In fact, I’d rather face a rabbied 800-pounds gorilla than use autowiring. Sure, it does all the job for you, doesn’t it?

During these (much deserved) vacations, I worked on a pet project of mine which uses CDI with the Weld implementation and SLF4J with the Logback implementation. The terms of the problem were very simple:  Iwanted the logs of my application to be displayed in a Swing table, i.e. a Logback appender had to write in a table. The table was managed in CDI but the appender was not: this was no surprise since many older-generation frameworks have a lifecycle management on their own.

No, those are not ingredients for a new fruit salad recipe. These are just the components I used in one of my pet project: it’ss a Swing application in which I wanted to try out CDI. I ended up with Weld SE, which is the CDI RI from JBoss. The application was tested alright with TestNG (regular users know about my preference of TestNG over JUnit) save the Swing GUI.

CDI is part of JavaEE 6 and that’s a great move forward. Now, there’s a standard telling vendors and developers how to do DI. It can be refined, but it’s here nonetheless. Norms and standards are IMHO a good thing in any industry. Yet, I don’t subscribe to some people’s points of view that this means the end of Spring. There are multiple DI frameworks around here and Spring is number one. Why is that? Because it was the first? It wasn’t (look at Avalon).

In one of my latest articles on +Context and Dependency Injection, one of the lessons I learned was to use factory methods in order to reduce the number of classes. In this article, I will go into the detail since I think it is of some importance. During school, you were probably taught to create a class for each component. For example, if your application has 4 buttons, North, East, South and West, you’ll have 4 classes.

Sinced I dived into CDI, I explored classical Java EE uses. Then, I used CDI into a pet project of mine to see how it could be used in Swing applications. This article sums up what lessons I learned from itthis far. This article assumes you have some familiarity with CDI; if not, please read my previous articles on CDI (CDI an overview part 1 and part 2) or read the documentation.

In the previous part of CDI, we saw some injection, qualifiers and scope. Now, it’s time to browse through more advanced features. Producers Previous examples cannot resolve all our use-cases. Some of these include: injection of random valuesinjection of context-dependent valuein general, places where the injection process cannot be narrowed down to a simple new() These hint at a very well-known pattern, the factory. Factories are implemented in JSR-299 as producers.

I may be a Spring fanboy but I’m also convinced a technology should embrace standards. Although Spring is now a de facto standard, it is in competition with other products, like Google Guice for example. It makes my work as an architect harder since my craft is to devise the most perennial solutions: standards are my allies in achieving this goal.