Thursday, May 29, 2014

7 Open Source Tools for Java Deployment

"If You Want To Go Fast, Go Alone. If You Want To Go Far, Go Together" - African proverb.
It's amazing to find out where a journey with a friend can lead you to. This particular journey began almost a year ago, and the friend I'm talking about is +Bruno Souza. I like to quote William T. Slobodian in my talks saying to my audience "Choose your friends wisely. You will become what they are." I certainly hope it's true, and yes, my choice was very wise.

We've been working together, talking and writing about Java, Cloud Computing, Continuous Deployment, DevOps, Software Automation and many other different things. This fruitful partnership resulted in many sessions in events like QConSP, JavaOne, The Developer's Conference, FISL, LinguÁgil, Campus Party and others. Our latest achievement, and so far the greatest one, is the "7 Open Source Tools for Java Deployment" article that we've written together and that made the cover of Oracle Java Magazine, May-June/2014 edition.

The article covers tools that will help you to build a sound deployment pipeline: reduced risks, smaller lead times, improved feedback and quality of life. The 7 tools are:
  1. Jenkins
  2. Chef
  3. Vagrant
  4. Packer
  5. Docker
  6. Flyway
  7. Rundeck
We've also included a bonus: an 8th tool that has just been open sourced a few weeks ago. 

Interested? Go check it out in the official Oracle Java Magazine website:

Tuesday, January 28, 2014

JSF 2.2 Native FileUpload

It took so many time that many have wondered if there would be the day when JSF had native file upload support. Well, the day has finally come. The scenario became to be set when JavaEE 6 brought Multipart support in the Servlets 3.0 specification. Now, in JavaEE 7 with Servlets 3.1 and JSF 2.2 we finally have the <h:inputFile> component.

(If you care to analyse the source code, FacesServlet in the Mojarra implementation of JSF is annotated with @MultipartConfig)

The JSF file upload implementation is quite simple, and the prerequisites are just two:
  1. Your <h:form>'s enctype attribute must be set to "multipart/form-data".
  2. Your <h:inputFile>'s value attribute must point to a bean property of type javax.servlet.http.Part.
Controller code for JFile Upload

Facelet code with <h:inputFile>

Sample application with upload running on Glassfish 4

Thursday, January 23, 2014

HTML Natural templating

Historically there has always been a gap in web application development between developers and designers. I have myself been struggled between some warm discussions about where one's responsibilities starts and the other's ends.

Designers know how to craft those beautiful HTML pages filled with images, CSS, JavaScript and standard tags. Developers transform that pleasant thing into something functional, "polluting" that designed template with technology-specific markup such as the JSF namespace markups.

JSF 2.2 brings the new feature of passthrough elements, which complements passthrough attributes. The specification term is "passthrough elements", but I'd like to refer to this feature as "Natural Templating" just like described in other framework's documentation. Why? Because natural templating is what you achieve, and passthrough elements is how you achieve it.

HTML natural templating allows your project's HTML files to become working prototypes. And when I say working prototypes it englobes any CSS or JavaScript code that you might have included in it. It means that any person (designer, customer, boss etc) can point-and-click your HTML files and have them correctly working on (hopefully) any web browser.

Natural templating also means that the designers in your team won't need a full-stack Java development environment to check if the rendered HTML is correct. They can produce their HTML, CSS and JavaScript files in whatever tools they want to and verify the results in their standard web browser by hitting "Refresh".

To add the intended functionality to these HTML templates, JSF developers only need to add custom attributes to standard HTML tags - which will be processed by the JSF implementation later at runtime. Best of both worlds.

If you need to know the attributes and their corresponding JSF component counterparts you will need to check the Javadocs for the TagDecorator class on

Notice: JSF 2.2 changed the way that the DOCTYPE instruction is processed. The default behaviour is to render the HTML5 DOCTYPE, so if you need a different DOCTYPE you should override it in the JSF configuration. Since JSF 2.2, the recommended way of coding your XHTML file is omitting the DOCTYPE declaration.

IntelliJ IDEA support for JSF 2.2 Natural Templating (aka passthrough elements).

Tuesday, January 21, 2014

HTML5 support with passthrough attributes

Prior to JSF 2.2 the responsibility of rendering the web page HTML code was delegated to the JSF component itself or its respective Renderer. This implied that only tags, attributes and styles already provided and hard coded in the component by its vendor could be used. Two problems aroused here. First, as HTML5 specification matured you couldn't render new attributes like placeholder or type on your inputs generated by existing JSF components. Second, you wouldn't also be able to use a non-standard attribute on an existing HTML element (for integration with frameworks like the now very popular Twitter-originated Bootstrap).

JSF 2.2 provides 3 different ways of solving this problem with passthrough attributes:

  1. Using the "" namespace and declaring the passthrough attributes as component attributes.
  2. Using the "<f:passThroughAttribute>" element and declaring each attribute declaratively.
  3. Using the "<f:passThroughAttributes>" element and using a bean property or method on your code that returns a Map<String,String>.
IntelliJ IDEA support for JSF 2.2 passthrough attributes

In all the cases the output generated by JSF (Mojarra implementation) is something like this:

You can notice the presence of the "type" and "placeholder" attributes as declared in the project.

JSF 2.2 New Namespaces

This isn’t a new feature, but a small change in the specification worth knowing about. If you’re already a JSF user you will notice that the namespaces for the tag libraries have changed. Don’t worry about changing your current code with the new namespaces, as the JSF specification explicitly requires both namespaces (old and new) to be supported by JSF implementations. Just make sure that on your new JSF code you use the new versions. Below you have a table with the old namespaces and their current counterparts:

Faces Core

IntelliJ IDEA support for new JSF namespaces

What's new in JSF 2.2?

With the release of JavaEE 7 many developers have struggled with the question: "What are the new features that JavaEE 7 brings to web development?" In this post series, we'll be dealing with the server-side web development component of JavaEE 7, namely JSF 2.2.

I've been a JSF developer since its initial version, 1.0, back in 2004. Since we're currently in 2014 this makes me kind of a JSF dinosaur, with nearly 10 years of experience. But I'm not sad about being old - in fact for JSF all these years have been very kind, and we can certainly assert that in its current version (2.2) JSF is one of the most compelling server-side web development frameworks available. Let's try to list some of its strong points:

  • Strong community
  • Big developer base
  • JSR-backed specification
  • Multiple component vendors
  • Strong IDE and tools support (IntelliJ IDEA included)
  • Active development
  • HTML5 support
  • Built-in & Natural templating
  • Stateful flow development
  • Part of JavaEE

Some of the above points may be subjective, but in the next few posts I hope to have presented some of the most relevant changes and new features brought by JSF 2.2 to developers; and also hope to have motivated you enough to consider migrating or upgrading to this new version.
  1. New namespaces
  2. HTML5 support with passthrough attributes
  3. HTML Natural templating
  4. FileUpload
  5. java.util.Collection support on DataModels
  6. Configurable Resources
  7. FacesFlow