Category Archives: CDI

CDI: Lazy Injection at Runtime or How to Obtain Every Matching Implementation

These days I’ve discovered a nice feature of CDI. What do you make of this code?

@Inject @Any
Instance<IValidator> validators;

Instance indicates that a single object is injected, but that’s quite the case. In my case the program uses the Instance like so:

for(IValidator validator:validators){
   validator.validate();
}

Obviously, @Inject Instance<IValidator> does something completely different than @Inject IValidator.
Continue reading

Running CDI on a Simple Tomcat

I’m big into CDI, but I’m not fond of application servers at all. So I’m bound to find out how to configure how to activate the CDI magic on a simple servlet container like Tomcat. That shouldn’t be too difficult. Mind you, it’s easy to run Weld (which happens to be the reference implementation of CDI) without a servlet container. However, in the past getting Weld on Tomcat proved to be a tad difficult, due to mediocre documentation.

Luckily, that has changed.

Jo Desmet (at least I suppose he’s the man behind the Musings in Java blog) has published a nice walk-through to get CDI and JSF on Tomcat 8 up and running. I followed his step-by-step tutorial and managed to activate CDI on my Tomcat 8 in a couple of minutes. Highly recommended!

However, no tutorial is so good it can’t be improved, so let me add one or two notes on it:

  • For some reason, declaring JTA and JSF as provided API and runtime implementation didn’t work for me. In theory, it should work, but I ended up adding both as compile time dependencies.
  • Jo didn’t say precisely where to put the context.xml and the beans.xml. I chose to put put into the src/main/webapp folder. To be pedantic, the context.xml went into the src/main/webapp/META-INF folder, and the beans.xml file went into the src/main/webapp/WEB-INF folder. (From what I remember from earlier experiments, both file should also work when put into the classpath – but I didn’t take the time to check this, too).

Cutting a long story short, you don’t need a full-blown application server just to use CDI!

TomEE-Based JavaEE Counterpart to Spring Boot

Spring Boot stirred up the Java world. Developers always put up stoically with slow server start-ups, long deployment times and difficult server configurations. Those times seem to come to an end. There’s only so much coffee you can drink during the breaks.

The disadvantage of Spring Boot is it uses Spring, excluding roughly half of the Java community. As far as I know you can’t use CDI on Spring Boot. Even if you were to find a way how to do it, it’s questionable if it’s wise to use two different dependency injection frameworks simultaneously.

So what about the JavaEE world? The TomEE team are currently exploring what needs to be done to implement a JavaEE counterpart to Spring Boot. These days Alex Soto published a surprisingly simple prototype (complete source code here).

At the moment it’s only a sketch which can run servlets and REST services. Spring Boot goes far beyond that: just think of the amount of effort that went into monitoring. Alex Soto’s prototype has a long way to go yet to become a real competitor. In any case he has announce to publish more source code soon on GitHub.

Be that as it may, even the current prototype can already be useful. In an earlier article (Application Servers are dead!) I’ve sketched how to embed Jetty or Tomcat in a JAR file. TomEE is much more complete. Embedded TomEE also brings CDI, EJBs, JSF and the rest of the JavaEE stack. Of course documentation is still sparse, but an adventurous developer should be able to implement a full-blown JavaEE application on the 70-lines prototype.

By the way, this isn’t the only project inspired by Spring Boot. After finishing the article I stumbled about a similar, less ambitious project. If you’re interested only in CDI and REST services, forseti may be worth a look. It’s a tiny project running on Jetty.

Dig deeper:

Alex Soto’s announcement
BeyondJava.net’s running copy of the source code
How to run JSF and PrimeFaces on Spring Boot
Application Servers are dead! (Sort of)

JSF 2.2 and PrimeFaces 5 on Spring Boot

Fork me on GitHubRecently I reported about Spring Boot (see Application Servers are dead! (Sort of)), an interesting approach to embed your application server into your application instead doing it the other way round.

However, Spring Boot is a fairly new technology, so the documentation is still work in progress. Most of the documentation is great, but there are still sentences like

Applications that are not already Spring applications might be convertible to a Spring Boot application, and the guidance above might help, but your mileage may vary.

Most JSF applications clearly fall into this category. So I’ve prepared a JSF template project to spare you some of the mileage. Currently there’s a simple simple PrimeFaces project and a more advanced project demonstrating Spring and JSF scopes.

To make things more interesting, I added Gradle and JSF custom scopes to the equation.
Continue reading

Glassfish 4.0 enables Method Level Contraints (Bean Validation 1.1)

A small addition to JavaEE 7 makes Design by Contract a lot more attractive to Java programmer. The idea is to annotate your method and / or the parameters of your methods with annotations. The most common case is @NotNull, indicating a particular parameter of a method must not be until.

public Customer findCustomer(
  @NotNull String login,
  @NotNull String password) {
  ...
}

Prior to JEE 7 this was merely a declaration of intent. Since JEE7 a ConstraintViolationException is raised if one of the annotations is violated. The interesting thing is this exception hasn’t anything to do with the GUI. Quite the contrary – there’s not integration into JSF. But then, you don’t need dedicated JSF support because the constraints are checked every time a method is called by CDI.
Continue reading

How to Integrate JSF 2 and Spring 3 (or Spring 4) Nicely

Oops. We did it again. We heeded the consultants advice once again.

You shouldn’t do that, you know. Not thoughtlessly, that is. It’s all right to call a consultant and listen to his advice. But don’t you follow his advice blindly. If he’s a good consultant, most of his advice is good. But every once in a while it’s just poisoned. A consultant’s job is to spread idea’s he’s already seen in other companies. In other words: he’s spreading something just above mediocrity. Respectable consultants don’t give really bad advices, but sometimes they kill good ideas they haven’t seen before – often without actually intending to do so.

An advice you definitely should not heed is to combine Spring and JSF. They simply aren’t made for each other. They aren’t exactly incompatible, but you have to split your application in two parts: JSF-land and Spring Country. Between those two countries there is a clearly defined border. Complete with fences, customs checks and everything else a frontier needs.

You’d rather use CDI with JSF. That’s a marriage made in heaven.

Unfortunately we did heed the consultants advice and abandoned CDI. Now it’s my team’s job to make the best of it.

Update (August 9, 2013)
Neill Griffin seems to have found a nice solution to the problem. Have a look at his announcement and his demo at GitHub. The solution even runs as a Liferay portlet.
Update (May 10, 2014)
Rafael Ponte reports in his comments (at the end of this article) the problem has been solved recently (Spring 3.2). He also reports it possible to avoid the serialization exception by adding the annotation @Scope(proxyMode=ScopedProxyMode.TARGET_CLASS, value="session") to the bean. The bean has to be injected as a manged property (@ManageProperty instead of @Autowired).
Continue reading