Two weeks ago I did a little tour around several JUGs and conferences to talk about dependency injections with CDI. The final goal of this road movie was to end up at GeeCon in Krakow. It was my second time at GeeCon and I have to say that this conference is like good wine : getting better with age. This community based conference is on its third edition and attracts people through out central and eastern Europe. Plenty of good speakers, nice location, skilled attendees... and a lot of fun (GeeCon organizers are party addicts). So make sure you mark this conference into your agenda for next year....
This is the second post based on pure CDI Injection (see Part I) after having talked about how to bootstrap CDI in several environments and how to add CDI to an existing Java EE 6 application. In this post I quickly want to show the different injection points in CDI : field, constructor and setter. To illustrate these different injection points I'll use a subset of the previous example : a servlet injecting an ISBN generator POJO ...
I haven't talked much lately at conferences or JUGs. The last one was Devoxx in November 2010 and I have been quite ever since (working on some other plans ;o) But it's time to do a bit of touring again. This time it will be Central Europe and the topic with injection in CDI. The presentation of the talk is To inject or not to inject: CDI is the question and the description roughly is :
After a quick introduction of CDI (Contexts and Dependency Injection) I will concentrate on dependency injection and the type-safe approach on injection in CDI. If you are fed up of using String based configuration, come to this talk and have a type-safe journey on CDI.
How come I am touring again ? Everything started with an invitation from my friends at GeeCon. I discovered GeeCon in 2009. It was the first edition of this conference in Cracow (Poland) created by the local user group.
Vos avez un nouveau projet dans les tuyaux ? Vous vous questionnez sur les frameworks à choisir ? Vous hésitez à utiliser votre framework printanier à base d'XML et de complexité ? Vous voulez migrer votre application vers un standard ? Vous détestez les EJBs ? J'ai ce qu'il vous faut : une formation de 3 jours autour de Java EE 6 intitulée Architectures d’aujourd’hui avec Java EE 6.
After writing a post about how to bootstrap CDI in your environment and giving you some tips about how to incorporate CDI in an existing Java EE 6 application, I want to talk about injection. Yes, pure injection or how to inject a bean into another one. As you'll see in this series of three articles (Part II), many different cases can happen. Let's start with a simple one : a straight forward injection.
The simplest possible injection case is... simple. You have something, and you inject something into it. Why am I using the word something ? Because until Java EE 5 we could only inject resources (EntityManager, Datasource, JMS destinations and factories...) into certain components (EJBs and Servlets). With CDI, you can inject nearly anything into anything else.
I like to investigate new things as well as digging into concepts that I know quite well. As an architect, my job is also to pass information to the teams I work for. I like writing articles because I can summaries what I know and give it to others who will learn from it. He are the abstracts of the articles I've written.
Tutorials on testing Java EE 6 components :
Antonio Goncalves, fondateur du groupe d'utilisateurs Java de Paris (Paris JUG)
(June, 2008) Personal interview covering my carrier, my travels around the world, my vision of French IT industry… till the creation of the Paris JUG.
If you haven't used your RSS feed reader lately, you might have missed that Java EE 7 is starting to kick off : JPA 2.1 (JSR 338) and JAX-RS 2.0 (JSR 339) have been voted, Robert Chinnici has talked about it, some conferences have mentioned it... Java EE 7 will happen and quite quickly (Q4 2012). The main focus is the cloud. I will not talk here about the cloud, I'll talk about everything else (well, not everything ;o)
Java EE 7 is an umbrella specification, meaning it's made of several specifications. Its goal is to give the other JSRs a common target (here, the cloud) and to make sure these specifications interact well with each other. The Java EE 7 expert group is not responsible for all the JSRs, just the umbrella. That means if the Java EE 7 expert group wants to add something new to the platform (eg. it would be nice to have batch processing into the platform) it will not do it : it will rely on some other spec (i.e. someone else) to specify it and to interact well with the other specs.