Farewell DrJUG. And thanks for everything!

Today was one of those days that I didn't want to have. But sometimes they happen. And even though I'm deeply sad it's my duty to write a few words for an incredible person and dear friend.

Daniel deOliveira was one of the few founding Java Champions. But saying he was a Java Champion is maybe too small for him: he was truly a Champion in many different other things and a Hero for many people. And I'm very relieved that he was able to receive the homage of a Duke's Choice Award at JavaOne 2015.

I deeply believe that all us are born for one specific reason: to leave a legacy. We should leave the world a better place compared to when we were born. And I'm very glad to say that I admire in the utmost level the kind of legacy that Daniel was able to leave for the whole Java Community, the Brazilian Community, and the world.

I was always impressed by his tireless efforts to join people together, to help people to learn Java as craft so that they could have a job and improve their lives, to help deaf people, and to much more. He dedicated his life to helping people, and I'm sure that many of us were touched by some of the magical effort that he did in the past 18 years as the leader of DFJUG.

Java and Java User Groups were such a passion for him that he decided to pursue a PhD degree using the Java User Group ecosystem as the basis of his thesis.

Even far away, living in Kent, UK, Daniel was still involved with DFJUG daily activities. One of these activities was the event that was held in Brasilia on October 29th, 2016. I am deeply honored for being one of the two speakers of this event. This was my first DFJUG event, and the last one with Daniel's presence. It was special for me, and now it's even more.

Daniel wrote an e-mail for me right after the event. I replied him on Monday. Daniel was always a quick replier. But I never got a response. Now I know why...

I could keep writing thousands lines about Daniel and his legacy. But I want to close this note with a huge Thank You. You did your job in a magnificent way. You are irreplaceable. But your legacy will be survived by the many people whose hearts and lives were impacted by you. I'm one of those.

Farewell my friend. And thanks for everything!

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: http://www.oraclejavamagazine-digital.com/

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

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 https://javaserverfaces.java.net/nonav/docs/2.2/javadocs/javax/faces/view/facelets/TagDecorator.html

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

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 "http://xmlns.jcp.org/jsf/passthrough" 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:

Library	Old URI	New URI
Composite Components	http://java.sun.com/jsf/composite	http://xmlns.jcp.org/jsf/composite
Faces Core	http://java.sun.com/jsf/core	http://xmlns.jcp.org/jsf/core
HTML_BASIC	http://java.sun.com/jsf/html	http://xmlns.jcp.org/jsf/html
JSTL Core	http://java.sun.com/jsp/jstl/core	http://xmlns.jcp.org/jsp/jstl/core
JSTL Functions	http://java.sun.com/jsp/jstl/functions	http://xmlns.jcp.org/jsp/jstl/functions
Facelets Templating	http://java.sun.com/jsf/facelets	http://xmlns.jcp.org/jsf/facelets
Pass Through Attributes	http://java.sun.com/jsf/passthrough	http://xmlns.jcp.org/jsf/passthrough
Pass Through Elements	http://java.sun.com/jsf	http://xmlns.jcp.org/jsf

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