Switching Datasource with CDI Alternatives and Stereotypes

Here we are, using H2 in our test environment, Derby in development and Postgres in production. It’s 2014, and Java EE still doesn’t have a decent configuration specification… So how do we change datasources in Java EE depending on our environment ? There are several possibilities (from external property files, Maven resource filtering, Maven profiles with different configuration … Continue reading

WYTIWYR : What You Test Is What You Run

I’m fed up with unit testing !

It’s 2012 and my first resolution of the year is to finally tell the truth about testing : unit testing is pretty much useless when your code runs inside a container. How do you unit test an EJB which relies on the container services (i.e transaction, injection, security…) ? Well, you mock the database access, you mock your security layer, you mock your dependencies, you mock your validation layer… to test what ? A bit of business logic. Yes. Unit test is interesting when you have complex business logic to test so you can have quick feedback. Otherwise, it’s a waste of time which doesn’t test your container services. So I’m not saying unit testing is completely useless, I’m saying that integration testing is also to be considered when you run your code inside a Java EE container.

Injection with CDI (Part III)

If you follow this blog you should know that latelly I’ve been writing (and talking) about CDI (Contexts and Dependency Injection). CDI has many aspects to it but until now I’ve focused on how to boostrap CDI in several environments, how to add CDI to an existing Java EE 6 application,  and more recently how to use injection with CDI. Actually this post is the third on CDI Injection : Part I focused on default injection and qualifiers, and Part II on all the possible injection points (field, constructor and setters). In this post I’ll explain producers or “how you can inject anything anywhere in a type safe manner“.

To inject or not to inject: CDI is the question

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….

Injection with CDI (Part II)

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

A week in central Europe… with CDI

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.

Injection with CDI (Part I)

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.

Default 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.

Adding CDI to an existing Java EE 6 application

In my previous post I’ve shown you how to bootstrap CDI in several environments (GlassFish, Tomcat, Jetty, Java SE). So now let’s go a bit further and use it in real code. As its name states, CDI (Contexts and Dependency Injection) is also about Dependency Injection, so let’s focus on just this feature for now. I will not define what DI (Dependency Injection) is. If you don’t know I’ll leave you to check the definition, the origins of this pattern and even a book that covers it all.

Bootstrapping CDI in several environments

I feel like writing some posts about CDI (Contexts and Dependency Injection). So this is the first one of a series of x posts (0<x<10). I will not go through the entire history of CDI (formerly called Web Beans, splitted in two JSRs… and so on), but will try to give you information on how to use it in different environments, explain you injection, context management, scoping, decorators and so on. So you can think of this series of posts as a humble step by step CDI tutorial. You can also read the very good documentation on the JBoss website (where I got some help and inspiration).

Follow

Get every new post delivered to your Inbox.

Join 7,493 other followers