Archive for the ‘Java’ Category

Vaadin and Spring integration through JavaConfig

March 9th, 2014 No comments

When I wrote the first version of Learning Vaadin, I hinted at how to integrate Vaadin with the Spring framework (as well as CDI). I only described the overall approach by providing a crude servlet that queried the Spring context to get the Application instance.

At the time of Learning Vaadin 7, I was eager to work on add-ons the community provided in terms of Spring integration. Unfortunately, I was sorely disappointed, as I found only few and those were lacking in one way or another. The only stuff mentioning was an article by Petter Holmström – a Vaadin team member (and voluntary fireman) describing how one should do to achieve Vaadin & Spring integration. It was much more advanced than my own rant but still not a true ready-to-be-used library.

So, when I learned that both Vaadin and Spring teams joined forces to provided a true integration library between two frameworks I love, I was overjoyed. Even better, this project was developed by none other than Petter for Vaadin and Josh Long for Pivotal. However, the project was aimed at achieving DI through auto-wiring. Since JavaConfig makes for a cleaner and more testable code, I filled an issue to allow that. Petter kindly worked on this, and in turn, I spent some time making it work.

The result of my experimentation with Spring Boot Vaadin integration has been published on, a blog exclusively dedicated to Vaadin.

Send to Kindle
Categories: JavaEE Tags: , ,

Chaining URL View resolvers in Spring MVC

February 16th, 2014 3 comments

Standard Java EE forward to internal resources go something like this:

public class MyServlet extends HttpServlet {

  public void doGet(HttpServletRequest req, HttpServletResponse resp) {

    req.getRequestDispatcher("/WEB-INF/page/my.jsp").forward(req, resp);

Admittedly, there’s no decoupling between the servlet code and the view technology, even not with the JSP location.

Spring MVC introduces the notion of ViewResolver. The controller just handles logical names, mapping between the logical name and the actual resource is handled by the ViewResolver. Even better, controllers are completely independent from resolvers: just registering the latter in the Spring context is enough.

Here’s a very basic controller, notice there’s no hint as to the final resource location.


public class MyController {

  public String displayLogicalResource() {

    return "my";

Even better, there’s nothing here as to the resource nature; it could be a JSP, an HTML, a Tiles, an Excel sheet, whatever. Each has a location strategy based on a dedicated ViewResolver. The most used resolver is the InternalResourceViewResolver; it meant to forward to internal resources, most of the time, JSPs. It is initialized like this:

  public ViewResolver pageViewResolver() {

    InternalResourceViewResolver resolver = new InternalResourceViewResolver();


  return resolver;

Given this view resolver available in the Spring context, the logical name "my" will tried to be resolved with the "/WEB-INF/page/my.jsp" path. If the resource exists, fine, otherwise, Spring MVC will return a 404.

Now, what if I’ve different folders with JSP? I expect to be able to configure two different view resolvers, one with a certain prefix, the other with a different one. I also expect them to be checked in a determined order, and to fallback from the first to the last. Spring MVC offers multiple resolvers with deterministic order, with a big caveat: it does not apply to InternalResourceViewResolver!

Quoting Spring MVC Javadoc:

When chaining ViewResolvers, an InternalResourceViewResolver always needs to be last, as it will attempt to resolve any view name, no matter whether the underlying resource actually exists.

This means I cannot configure two InternalResourceViewResolver in my context, or more precisely I can but the first will terminate the lookup process. The reasoning behind (as well as the actual code), is that the resolver gets an handle on the RequestDispatcher configured with the resource path. Only much later is the dispatcher forwarded to, only to find that it does not exist.

To me, this is not acceptable as my use-case is commonplace. Furthermore, configuring only "/WEB-INF" for prefix and returning the rest of the path ("/page/my")  is out of the question as it ultimately defeats the purpose of decoupling the logical name from the resource location. Worst of all, I’ve seen controller code such as the following to cope with this limitation:

return getViews().get("my"); // The controller has a Map view property with "my" as key and the complete path as the "value"

I think there must be some more Spring-ish way to achieve that and I’ve come to what I think is an elegant solution in the form of a ViewResolver that checks if the resource exists.

public class ChainableUrlBasedViewResolver extends UrlBasedViewResolver {

  public ChainableUrlBasedViewResolver() {


  protected AbstractUrlBasedView buildView(String viewName) throws Exception {

    String url = getPrefix() + viewName + getSuffix();

    InputStream stream = getServletContext().getResourceAsStream(url);

    if (stream == null) {

      return new NonExistentView();

    return super.buildView(viewName);

  private static class NonExistentView extends AbstractUrlBasedView {

    protected boolean isUrlRequired() {

        return false;

    public boolean checkResource(Locale locale) throws Exception {

      return false;

    protected void renderMergedOutputModel(Map<String, Object> model,
                                           HttpServletRequest request,
                                           HttpServletResponse response) throws Exception {

      // Purposely empty, it should never get called

My first attempt was trying to return null within the buildView() method. Unfortunately, there was some NPE being thrown later in the code. Therefore, the method returns a view that a. tells caller that the underlying resource does not exist b. does not allow for its URL to be checked (it also fails at some point if this is not set).

I’m pretty happy with this solution, as it enables me to configure my context like that:

@ComponentScan(basePackages = "")
public class WebConfig {

  public ViewResolver pageViewResolver() {

    UrlBasedViewResolver resolver = new ChainableUrlBasedViewResolver();


    return resolver;

  public ViewResolver jspViewResolver() {

    InternalResourceViewResolver resolver = new InternalResourceViewResolver();


    return resolver;

Now, I’m pretty well inside Spring philosophy: I’m completely decoupled, and I’m using Spring nominal resolver ordering. The only con is that one resource can shadow another another by having the same logical name pointing to different resources given different view resolvers. As it is already the case with multiple view resolvers, I’m ready to accept the risk.

A showcase project can be found here in IntelliJ IDEA/Maven format.

Send to Kindle
Categories: JavaEE Tags:

Reusing front-end components in web applications

February 9th, 2014 2 comments

In the Java SE realm, GUI components are based on Java classes with the help of libraries such as AWT, Swing or the newer JavaFX. As such, they can be shared across projects, to be inherited and composed.

Things are entirely different in the Java EE world, as GUI components are completely heterogeneous in nature: they may include static HTML pages, JavaScript files, stylesheets, images, Java Server Pages or Java Server Faces. Solutions to share these resources must be tailored to each type.

  1. Since Servlet 3.0 (Java EE 6), static resources, such as HTML, JavaScript, CSS and images can be shared quite easily. Those resources need to be packaged into the META-INF/resources folder of a JAR. At this point, putting the JAR inside the WEB-INF/lib folder of a webapp will make any such resource available at the webapp’s context root.
    A disadvantage of this approach is that shared resources are also exposed publicly, including JSP that are not meant to be.
  2. An alternative to share resources protected under WEB-INF, which is also available before Servlet 3.0, is to leverage the build tool. In this case, Maven offers a so-called overlay feature through the Maven WAR plugin. This requires both adding the WAR containing resources and dependencies as well as some POM configuration.

    At this point, resources belonging to the dependent WAR artifact will be copied to the project at build-time. Not resources existing in the project may be overwritten… on purpose or by accident. The biggest disadvantage of WAR overlays, however, is that resources have to be packaged in the WAR artifact while corresponding classes have to be in another JAR artifact.

  3. I’ve not much experience in Java Server Faces technology, but it seems sharing pages across different webapps requires the use of ResourceResolver.
  4. Finally, some frameworks are entirely built toward sharing GUI resources. For exaemple, with Vaadin, GUI components are based on Java classes, as for Java SE, thus making those components inheritable and composable. Furthermore, using images can be achieved in a few lines of code and is easy as pie:
    Image image = new Image("My image", new ClassResource("ch/frankel/blog/resources/image.png"));

I think Java EE is sadly lacking regarding reuse of front-end resources. Of course, one can choose client-based frameworks to overcome this limitation though they bring their own pros and cons. In all cases, ease of reuse should be an important criteria for choosing front-end technologies.

Send to Kindle
Categories: JavaEE Tags: ,

Extrinsic vs intrinsic equality

January 26th, 2014 5 comments

Note: the following article is purely theoretical. I don’t know if it fits a real-life use-case, but the point is just too good to miss :-)

Java’s List sorting has two flavors: one follows the natural ordering of collection objects, the other requires an external comparator.

In the first case, Java assumes objects are naturally ordered. From a code point of view, this means types of objects in the list must implement the Comparable interface. For example, such is the case for String and Date objects. If this is not the case, or if objects cannot be compared to one another (because perhapsthey belong to incompatible type as both String and Date).

The second case happens when the natural order is not relevant and a comparator has to be implemented. For example, strings are sorted according to the character value, meaning case is relevant. When the use-case requires a case-insensitive sort, the following code will do (using Java 8 enhanced syntax):

Collections.sort(strings, (s1, s2) -> s1.compareToIgnoreCase(s2));

The Comparable approach is intrinsic, the Comparator extrinsic; the former case rigid, the latter adaptable to the required context.

What applies to lists, however, cannot be applied to Java sets. Objects added to sets have to define equals() and hashCode() and both properties (one could say that it’s only one since they are so coupled together) are intrinsic. There is no way to define an equality that can change depending on the context in the JDK.

Enters Trove:

The Trove library provide primitive collections with similar APIs to the above. This gap in the JDK is often addressed by using the “wrapper” classes (java.lang.Integer, java.lang.Float, etc.) with Object-based collections. For most applications, however, collections which store primitives directly will require less space and yield significant performance gains.

Let’s be frank, Trove is under-documented. However, it offers what is missing regarding extrinsic equality: it provides a dedicated set implementation, that accepts its own extrinsic equality abstraction.

A sample code would look like that:

HashingStrategy<Date> strategy = new MyCustomStrategy();

Set<Date> dates = new TCustomHashSet<Date>(strategy);

A big bonus for using Trove is performance, though:

  1. It probably is the first argument to use Trove
  2. I never tested that in any context

To go further, just have a look at Trove for yourself.

Send to Kindle
Categories: Java Tags:

WebJars and wro4j integration

January 19th, 2014 3 comments

WebJars is an easy way for server-side developers (such as your humble servant) to manage client-side resources such as Bootstrap, jQuery and their like, within the same package management tool they use for their server-side libraries.

In essence, what WebJars does is package a set version of the client-side resource (CSS or JavaScript) in the META-INF/resources of a JAR and upload it on Maven Central. Then, any Java EE compatible web-container makes the resource available under a static URL. For example, for a JAR packaging META-INF/resources/webjars/bootstrap.3.0.3/js/bootstrap.js, it can be referenced by webjars/bootstrap/3.0.3/css/bootstrap.css.

Most providers offer a minified version of their resource, and it is packaged along in the JAR, so using a minified resource is a no-brainer (if the minified resource is packages along, of course). However, when using multiple WebJars, this increases the number of browser requests. Outside the context of WebJars, minimizing the number of requests could easily be achieved by using wro4j, a tool that manages both minifying and merging resources through lists of pre- and post-processors. A typical wro4j use-case was already described in an earlier article.

The good thing is that WebJars and wro4j can be integrated with ease through wro4j.xml configuration file. As it stands, wro4j.xml configures resources merging. Those resources may come from a variety of sources; typically, they are internal resource and are referenced by their path relative from the webapp root:


However, the power of wro4j is to be able to reference other kind of resources, including those packaged inside JARs:


And with this configuration line only, we merge the resource inside the WebJar with other resources. From this point on, the merged resource can be referenced as the single resource inside our webapp. The following displays a wro4j configuration file that creates a compound.css file from an internal sample.css and the Bootstrap WebJar.

<?xml version="1.0" encoding="UTF-8"?>
<groups xmlns="">
    <group name="compound">

An example project in Maven/IntelliJ format is provided as an attachment.

Warning: though having a single minified resource for JavaScript (and one for CSS) improves performance with HTTP/1.1, it seems it might not be the case with HTTP/2.0.

Send to Kindle
Categories: Java Tags: , , , ,

Guava is an heavyweight library and I would like this to change

January 12th, 2014 4 comments

Google Guava is an useful library that offers many different but unrelated features:

However, this article is not about those features but about offering a single heavyweight Uber JAR for all. From Google’s point-of-view, providing an Uber library for all projects makes sense: “Hey guys, just add this dependency and it will meet your every requirement”. However, from my point of view, this is just making my applications heavier.

Cohesion is at the root of good software development. Many framework providers, such as Spring and JBoss, release nicely cohesive packages and manage dependencies between them through a Dependency Management tool. What is strange is that most Guava’s features are not coupled together, so a having single library is not mandatory. Even stranger, Guava has previously been released in different JARs but Google stopped doing that with version r03.

I have found no solution beside creating separate JARs and handling dependencies myself, then storing them in a Maven Enterprise Repository. Since these tasks are required for each release, I never found the ROI interesting enough. The easiest way would be for Google to do that at build time.

Dear Google engineers, if by chance you happen to stumble upon this article, I’d be very grateful if you’d consider it.

Send to Kindle
Categories: Java Tags: ,

Solr, as a Spring Data module

December 1st, 2013 No comments

At the end of October, I attended a 3-days Solr training. It was very interesting, in light of the former Elastic Search talk I attended mid-year. As an old Spring Data fan, when I found out Spring Data offered a Solr module, I jumped at the chance to try it.

In this case, I’m well aware that an abstraction layer over Solr doesn’t mean we can easily change the underlying datastore: Solr is designed as an inverted index, while other Spring Data modules are much more specialized (JPA, MongoDB, etc.). However, there are still some advantages of using Spring Data over Solr:

  • Quick prototyping, when you don’t need the whole nine yards
  • Use Solr when most of the team already knows about Spring Data and not Solr
  • Spring integration from the bottom
  • Last but not least important of all, you can easily switch between the embedded Solr and the standalone one. Spring Data nicely wraps both the Solrj API and HTTP behind its own API. If you think this is not a relevant use-case as it never will happen, think about integration testing

After having initialized Solr with relevant data, here are steps you have to go through to start developing:

  1. The initial step is to configure the Spring context with the underlying Solr. Spring Data Solr requires a bean named solrTemplate of type SolrOperations. Let use the JavaConfig for this:
    public class JavaConfig {
        protected HttpSolrServerFactoryBean solrServerFactory() {
            HttpSolrServerFactoryBean factory = new HttpSolrServerFactoryBean();
            return factory;
        public SolrOperations solrTemplate() throws Exception {
            return new SolrTemplate(solrServerFactory().getObject());
  2. Create the managed entity. All fields stored in Solr have to be annotated with @Field. If the entity attribute name is different from Solr field name, @Field accepts a value to override the name:
    public class Loan {
        private String id;
        private String governmentType;
        // Getters and setters
  3. Create the repository interface: either inherit from SolrRepository<Bean,ID> or SolrCrudRepository<Bean,ID>. Note the former only provides the count() method.
    public interface LoanRepository extends SolrRepository<Loan, String> {}
  4. Add query methods to the former interface:
    • Simple query methods benefit from Spring Data parsing: List<Loan> findByLoanType(String) will translate into ?q=loan_type:...
    • More advanced queries (or method whose name do not follow the pattern) should be annotated with @Query@Query("state_name:[* TO *]") will find all loans which have a value for state_name. The annotation can bind as many parameters as necessary, through the use of ?x where x is the parameter index in the method parameters list.
    • Facets are also handled through the @Facet annotation, which takes the field names the facet should use. This changes the method signature, though, to a FacetPage and it is up to the calling method (probably located the service layer) to handle that.

The final class should look something like that, which is awesome considering all capabilities it provides:

public interface LoanRepository extends SolrRepository<Loan, String> {

    List<Loan> findByLoanType(String loan);

    List<Loan> findByTitleContaining(String title);

    @Query("state_name:[* TO *]")
    List<Loan> findLocalized();

    @Facet(fields = "loan_type")
    FacetPage<Loan> findAllLoanTypes(Pageable page);

The entire project source code is available there in IntelliJ/Maven format, complete with tests. Note that you’ll need a running Solr instance with a specific Solr schema and documents in it. Both the schema and the document files (federal.xml) are provided, but those are not automated: you’ll need to overwrite your schema and the document file to the running instance (with the classic java -jar post.jar command line).

To go further:

Send to Kindle
Categories: Java Tags: ,

Spreading some JavaFX love

November 24th, 2013 1 comment

I’m not a big fan of JavaFX: version 1 was just a huge failure, and investing in fat-client architecture in 2013 is either because you have very specific needs or are completely out of your mind. Nevertheless, I wanted to write about fat-client testing in “Integration testing from the trenches”, and JavaFX is the Java way for fat-client GUI.

So I was searching for some easily available application I could take as an example when I stumbled upon the Ensemble samples project from Oracle itself. Sources are available so I thought this could be a good match. Nothing could be further from the truth, the project is plagued by pitfalls:

  1. It seems the good people at Oracle had to choose between promoting NetBeans and JavaFX and their priority was on the former. Sources are available in NetBeans format. Tough luck if you don’t use it as your IDE…
  2. NetBeans uses Ant as its underlying build tool. Not only are Java sources and binary resources stored in the same directories, you have to read carefully through the build file to tweak some things.
  3. The code itself distinguishes between running from sources or from JAR. In the former case, it uses a text file listing all the desired samples to include, but it is built by the Ant build, and if it’s not present (or empty), you get a not-so-nice NullPointerException.
  4. Even worse, though JavaFX runtime is included in JRE 7, it isn’t on the classpath.

I think that putting such obstacles in the way of developers is hardly the thing to do to promote a technology. In order to fix those problems, I decided to tackle this heads-on, so I’ve created a Maven project. I changed no code, just moved resources around to adapt to the Maven standard project structure and provided the required text file.

The whole project is on Github, you’re welcome to give it a try!

Send to Kindle
Categories: Java Tags:

Integrate Spring JavaConfig with legacy configuration

November 9th, 2013 1 comment

The application I’m working on now uses Spring both by parsing for XML Spring configuration files in pre-determined locations and by scanning annotations-based autowiring. I’ve already stated my stance on autowiring previously, this article only concerns itself on how I could use Spring JavaConfig without migrating the whole existing codebase in a single big refactoring.

This is easily achieved by scanning the package where the JavaConfig class is located in the legacy Spring XML configuration file:

<ctx:component-scan base-package="" />

However, we may need to inject beans created through the old methods into our new JavaConfig file. In order to achieve this, we need to autowire those beans into JavaConfig:

public class JavaConfig {

    private FooDao fooDao;

    private FooService fooService;

    private BarService barService;

    public AnotherService anotherService() {

        return new AnotherService(fooDao);

    public MyFacade myFacade() {

        return new MyFacade(fooService, barService, anotherService());

You can find complete sources for this article (including tests) in IDEA/Maven format.

Thanks to Josh Long and Gildas Cuisinier for the pointers on how to achieve this.

Send to Kindle
Categories: Java Tags: ,

My case against autowiring

November 3rd, 2013 8 comments

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

Autowiring basics

Autowiring flavors

Autowiring comes into different flavors:

  • Autowiring by type means Spring will look for available beans that match the type used in the setter. For example, for a bean having a setCar(Car car) method, Spring will look for a Car type (or one of its subtype) in the bean context.
  • Autowiring by name means Spring search strategy is based on beans name. For the previous example, Spring will look for a bean named car regardless of its type. This both requires the bean to be named (no anonymous bean here) and implies that the developer is responsible for any type mistmatch (if the car bean is of type Plane).

Autowiring is also possible for constructor injection.

Autowiring through XML configuration

Let’s first dispel some misconceptions: autowiring does not imply annotations. In fact, autowiring is available through XML since ages and can be enabled with the following syntax.

<bean autowire="byType" class="some.Clazz" />

This means Spring will try to find the right type to fill the dependency(ies) by using setter(s).

Alternative autowire parameters include:

  • by name: instead of matching by type, Spring will use bean names
  • constructor: constructor injection restricted to by-type
  • autodetect: use constructor injection, but falls back to by-type if no adequate constructor is found

Autowiring through annotations configuration

Available annotations are the following:

Annotation Description Source
 org.springframework.bean.factory.@Autowired  Wires by type  Spring 2.5+
 javax.annotation.@Resource  Wires by name  JavaEE 5+
 javax.inject.@Inject  Wires by type  JavaEE 6+
javax.inject.@Qualifier  Narrows type wiring  JavaEE 6+

Dependency Injection is all about decoupling your classes from one another to make them more testable. Autowiring through annotations strongly couples annotated classes to annotations libraries. Admittedly, this is worse for Spring’s @Autowired than for others as they are generally provided by application servers.

Why it is so bad after all?

Autowiring is all about simplifying dependency injection, and although it may seem seductive at first, it’s not maintainable in real-life projects.

Explicit dependency injection is – guess what, explicitly defining a single bean to match the required dependency. Even better, if Java Configuration is used, it is validated at compile time.

On the opposite, autowiring is about expressing constraints on all available beans in the Spring context so that one and only one matches the required dependency. In effect, you delegate wiring to Spring, tasking him to find the right bean for you. This means that by adding beans in your context, you run the risk of providing more than one match, if your previous constraints do not apply to the new beans. The larger the project, the larger the team (or even worse, the number of teams), the larger the context, the higher the risk.

For example, imagine you crafted a real nice service with a single implementation, that you need to inject somewhere. After a while, someone notices your service but creates an alternative implementation for some reason. By just declaring this new bean in the context, along with the former, it will break container initialization! Worse, it may be done in an entirely different part of the application, with seemingly no link with the former. At this point, good luck to analyze the reason of the bug.

Note that autowiring by name if even worse, since bean names have a probability of collision, even across different type hierarchies.

Autowiring is bad in Spring, but it is even worse in CDI where every class in the classpath is a candidate for injection. By the way, any CDI guru reading this post care to explain why autowiring is the only way of DI? That would be really enlightening.


In this post, I tried to explain what is autowiring. It can be used all right, but now you should be aware of its con. IMHO, you should only use it for prototyping or quick-and-dirty proof of concepts, everything that can be discarded after a single use. If really needed, prefer wiring by type over wiring by name as at least it matching doesn’t depend on a String.

Send to Kindle
Categories: Java Tags: , ,