Everything started when Eve said ‘No‘ when God told her not to eat the fruit. Then my daughter said ‘No‘ when I told her to clean her room. Then we had a bunch of guys saying ‘No‘ to SQL. Then I read Is there such a thing as the NoMock movement?… And today I’m saying let’s launch the NoMock Movement […]
Stephen Chin had this crazy idea of touring Europe on its way to Devoxx, and interview people. He called it the “Hacking Tour – The Road to Devoxx“. On his way from Italy he crossed France, stopped over to interview several people and then he arrived in Paris to interview me as well as the Parisian Java community (Paris JUG, […]
A short blog about a topic I was discussing last week with a customer: testing SOAP Web Services. If you follow my blog you would know by now that I’m not a fan of unit testing in MOCK environments. Not because I don’t like it or I have religious believes that don’t allow me to use JUnit and Mockito. It’s just because with […]
If you are interested by Java EE development and roadmap you might have read recently that the Cloud feature in Java EE 7 has been delayed. As I’ve already expressed in the Java EE 7 expert group mailing list, I’m happy about this news because I feel standardizing cloud in EE 7 was way too early. But I’m also sad. Sad because […]
Do you remember the good old Java Petstore ? It was a sample application created by Sun for its Java BluePrints program. The Java Petstore was designed to illustrate how J2EE (and then Java EE) could be used to develop an eCommerce web application. Yes, the point of the Petstore is to sell pets online. The Petstore had a huge […]
I.T. is full of complex things that should (and sometimes could) be simple. Getting the JQPL/SQL String representation for a JPA 2.0 CriteriaQuery is one of them. By now you all know the JPA 2.0 Criteria API : a type safe way to write a JQPL query. This API is clever in the way that you don’t use Strings to build […]
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.
Nearly two years ago (time flies), when Java EE 6 came out, I wrote a post about application servers where I did some micro benchmarking (basically, startup time). I had plenty of comments and recently I had many people asking for some updates. Witht Java EE 6 booming, with some cloud vendors moving to Java EE 6, it was time to update this microbenchmark and focus on Java EE 6 application servers. BTW, if you want to know what Java EE 6 is, you can check the slides of a presentationI gave a few times.
Same disclaimer as last time : This is not a real benchmark ! so I'll copy paste the paragraph I wrote last time :
In this test I’m just concerned about the usability of an application server for a developer. The idea is to download it, install it, start it and take some measurements : size of download, ease of installation, size of disk, startup time, size of RAM.
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".
I've been asked so many times "what are the implementations of such or such specification in Java EE 6 ?" or "what is the reference implementation of such a spec ?". Because I always forget some (and to be honest, sometimes I don't even know if a spec has several implementations of not), I'm writing this post to help me (and you) to remember.
So here is a non-exhaustive list of the several Java EE 6 implementations (please leave a comment to add anything to this list) ...
How do you configure your enterprise application ? Or to be more precise "what is configuration, what can you configure in Java EE and how can you configure it ?"
What is configuration ?
Sometimes your application needs to change parts of its behavior at deployment time. You then need to provide some external configuration for some components. For example, in your development environment you don't want to use a datasource and instead hit the database with a user & password, in your test environment you lookup for the datasource and use it. If you deploy your application in Europe you need to use the Euro as the current currency and if you deploy it in the US you need dollars...
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.
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.
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).
Vous l'avez certainement lu dans tous les magasines, la rentrée littéraire 2010 ce n'est ni Michel Houellebecq ni Amélie Nothomb, mais bel et bien la seconde édition de Java EE 6 (aux éditions Apress). Pour fêter cet évènement inter galactique, je m'associe à Emmanuel Bernard (Hibernate Search in Action aux éditions Manning) et Arnaud Héritier (Maven aux éditions Pearson) pour une séance de dédicace groupée à la librairie Le Monde en Tique. Vous aurez ainsi l'honneur et le privilège de rencontrer vos idoles, d'acheter leur superbe ouvrage, de vous les faire dédicacer, de boire un verre et de papoter de tout et de rien.
I haven't blogged for quite a long time. That's not because I am lazy (well, I took 4 weeks of holidays) or I have nothing to say (titles you could have read in this blog "the rise of Java EE 6", "the lightweight container strikes back", "in EJB we trust" or "god save CDI"). No, I was busy finishing the second edition of Beginning Java EE 6 with GlassFish v3.
This second edition has many updates. I've updated all the tools of course (GlassFish 3.0.1, Derby 10.6, JDK 1.6.0_20...) but also added extra sections (on JPA, EJB, JSF & JAX-RS) as well as taking into account readers' feedback. I would like to thank everybody who read the first edition and sent me feedback on Get Satisfaction. That allowed me to correct some mistakes or clarify some concepts. If you get the book, remember to download the code of the examples from Kenai. I've also updated lots of code, improved javadoc and added some readme.txt files.
It's been a long time since I haven't blogged about what I am doing on evenings and week-ends. For people who think that I watch TV and have BBQs on Saturdays, I have to tell you that I don't have any TV (it's been over 20 years now) and I don't have a garden to cook my burgers. No, I've spent my spare time updating my Java EE 6 book.
In this second edition I have updated the content and added new sections. When the first version of the book got out it was in June 2009 and Java EE 6 hadn't been released yet (December 2009). So there were some topics that I didn't cover because they were not completely finished (like the Criteria API in JPA 2.0). I've also updated the frameworks (GlassFish 3.0.1) and the code so it's more accurate. The book is planned to be published in September 2010. As always there is a full list of people I need to thank for this second edition. Writing or updating a book is hard work and comfort is always needed.
For those of you who have followed the JPA 2.0 specification, you might have come across the new Criteria API. The main idea of this new API is to be able to write a JPQL query using an object-oriented way (through a rich API) instead of a String. For example, if you want to return the list of all customers […]
For those of you who still don’t know Bean Validation, you should check the JSR 303 and the documentation of the reference implementation Hibernate Validator. In fact, like many other JSRs, Hibernate Validator existed on its own for quite a long time as an open source project (until version 3.1.x) and then got specified under the JSR 303 and became the reference implementation from its version 4.x. Bean Validation 1.0 was born and is now part of Java EE 6. But keep in mind that Bean Validation doesn’t need Java EE 6 to run (like other specs such as JPA 2.0, JSF 2.0, CDI 1.0…) and can be used outside any container. So, what is it for ? Well, the short answer is to validate your POJOs. Imagine that you have a Book POJO and you want to check that the title of the book is not null and the author’s name is greater than 5 caracters and shorter than 20. Where do you validate these simple business rules ? In which later ? Different schools exist. In the Anemic Domain Model school, your model doesn’t have any intelligence and the validation should be done outside (typically in a service layer). In the Rich Object Model school, the object should validate itself and is the best place to encapsulate its own business logic. Bean Validation is part of the second school. So, how do you add validation constraints to your POJO […]