A Java geek

Dear readers,

Thanks for your participation in the ‘Learning Vaadin’ contest. It’s my pleasure to announce the winners:

• Adolfo Benedetti who commented on the integration side of ‘Learning Vaadin’
• Sebastian who also commented about integration
• A. Jansenn who noted the Vaadin team is very positive about ‘Learning Vaadin’ and that it’s a good complement to the available documentation

The winners will be contacted by a Packt representative about the details.

The choice was hard and I know there will be some deception for not having won a copy. Nevertheless, you can always purchase the book at Packt or Amazon.

To celebrate the release of my new book, Learning Vaadin, Packt is giving away 3 copies especially to my blog readers. Keep reading to find out how you can be one of the lucky winners.

Overview of Learning Vaadin

• Discover the Vaadin framework in a progressive and structured way
• Learn about components, events, layouts, containers, and bindings

Read more about this book and download a free sample chapter.

How to Enter?

Head on over to the book page and look through the product description and drop a line via the comments below to let us know what interests you the most about this book and why you would recommend it to your friends.

Winners

Winners will be choosed from the commenters, based on the interest and relevance of the comments. Winners from the U.S. and Europe will be able to either choose a physical copy of the book or the eBook. Users from other locales are limited to the eBook only.

The contest will close on Friday, the 25th of November at midnight (Central European Time). Winners will be contacted by email, so be sure to use your real email address when you comment!

This is it! After 10 monts of work, my first book is out: ‘Learning Vaadin’ is now available at Packt and Amazon.

First things first, what’s is Vaadin? Vaadin is a presentation-layer web framework that let you easily develop Rich Internet Applications. It does so by provding an abstraction over the Servlet API and by letting developers assemble components to design screens (as opposed to pages as in previous generation web frameworks). If you got 5 minutes to spare, you can go try the tutorial and be convinced yourself. Note that I do not hold Vaadin for a golden hammer, but in most contexts, it just is the right tool.

Now, why write a book? An imperative prerequisite is to believe in the subject. For me, it was love at first sight… I already wrote on Vaadin and used it in real pre-sales demos. During a conversation with Joonas Lehtinen, Vaadin’s CEO, he mentioned he had been approached by Pack to write a book on the subject. My brain processed the information and mere minutes later, I proposed myself.

Although writing a book is like coding in a project in many ways: there’s a schedule, limited time, reviewing (testing), rewriting (bug fixing), ups and downs, it has not been easy for me. I’m admirative of people who regularly write books in their spare time. They need discipline, of course, but also a supportive family and the right publisher. Fortunately, I had these assets this time and I’m now proud to have finished the book.

But is it finished? The strangest is that I do not realize yet. I’m waiting to hold a hard-copy in my hands to really think ‘I’ve done it’. Once received, I believe I will be entitled to some much-deserved R&R

‘Learning Vaadin’ in the news:

• DZone: “Meet the author: Learning Vaadin”
• Vaadin: “New book: Learning Vaadin”
• Vaadin: ‘Learning Vaadin’ side by side with the Book of Vaadin!
• Knowledge Black Belt (aka Black Belt Factory aka Java Black Belt):“Vaadin Book”
• Java.net: Fabrizio Giudici also mentions ‘Learning Vaadin’ at the end of a post where he thanks Vaadin for making it possible to deliver 3 weeks in advance… Think it over

You’re welcome to mention other references I may have missed.

This week, I was faced with what seemed an near-insuperable problem. I was called by one of my dev: as soon as he upgraded his Eclipse (or more precisely, our own already-configured Eclipse), he couldn’t deploy to Tomcat through WTP. Here are the steps I took to resolve the problem and more general thoughts about upgrading and tooling.

The log displayed a ClassNotFoundException, one involving Spring. So, the first step is to look under the hood. Provided you used the default configuration – to use workspace metadata – it should be located under <WORKSPACE>/.metadata/.plugins/org.eclipse.wst.server.core/tmp<i>/wtpwebapps where WORKSPACE is your workspace location and i is an incremental number beginning with 0 assigned by Eclipse to each virtual application server in WTP. There you should see the applications deployed in Eclipse. When I checked, I realized the application was deployed alright, but found no WEB-INF/lib folder.

I had already experienced such deployment problems: I solved them by first forcing publish (right-click on the server and choose Publish) and if not successful, cleaning (it removes all deployment and starts again from scratch). Well, this didn’t work.

Also, sometimes classes are not deployed because there aren’t there in the first place: compilation doesn’t occur (because of bad code or Eclipse may be playful) and this prevents generating .class files. This didn’t seem like the problem but hell, this was a lead like any other. In order to force compilation, clean the project and check recompile afterwards (or check auto build is on). This didn’t work too…

It happened before that closing the project and reopening it resolved some code-unrelated compilation problems. Closing and restarting Eclipse may yield the same results. I did both to no avail. At this point, I was disappointed because all previous steps should have resolved the problem… yet they hadn’t.

Since the project used Maven (and we had m2eclipse installed), I also checked the Maven Dependencies library was correctly referenced: it was. Just to be sure, I disabled and re-enabled dependencies management. Guess what? Nothing changed.

Desperate, I hopelessly browsed through the POM and the following caught my attention:

<plugin>
 <artifactId>maven-war-plugin</artifactId>
 <configuration>
 <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
 </configuration>
</plugin>

This configuration creates skinny WARs so that libraries are not packaged in the WAR but are in the EAR, provided they are referenced, of course (for the right way to create such WARs, see my post from last week). With a faint gleam of hope, I removed the configuration part and it worked, the libraries were finally deployed.

Yes, dear readers, it seems newer versions of the m2eclipse plugin are able to parse some portions of the POM that were not parsed before and act accordingly. Although this is a good news in general, it means we have to carefully check about potential side-effects of upgrading to those newer versions. Of course, this was stupid to upgrade in the first place but think that sometimes it’s mandatory for a newer project.

However, the problem is much more widespread than m2eclipse. It’s very similar to issues adressed in Andrew Spencer’s post, only more so since if we don’t upgrade, we may have to keep an Eclipse instance for each project, that has to be shared between all team members. Right now, I don’t have any solutions for this problem, apart from changing the code to keep in synch with the tool.

PS : since we still wanted to have skinny WARs, I just moved the configuration part in a profile… which was what was configured in the archetype provided by the support team

In a previous post, I wrote about how to create skinny WAR with Maven the DRY way: it was not the DRYier way to do it, as was demonstrated to me this week by my colleague Olivier Chapiteau (credit where credit is due).

His solution is far more elegant; it is reproduced below for reference’s sake.

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <dependencies>
    <dependency>
      <groupId>ch.frankel.blog.ear-war</groupId>
      <artifactId>war-example</artifactId>
      <version>1.0.0</version>
      <type>war</type>
    </dependency>
    <dependency>
      <groupId>ch.frankel.blog.ear-war</groupId>
      <artifactId>war-example</artifactId>
      <type>pom</type> <!-- Here works the magic -->
      <version>1.0.0</version>
    </dependency>
  </dependencies>
...
</project>

That’s it! The beauty lies in using the WAR’s POM as a dependency as well as the WAR itself: it’s simple, DRY and effective.

One thing I’m doing very often and always searching on the Internet is how to obtain a self-signed SSL certificate and install it in both my client browsers and my local Tomcat.

Sure enough there are enough resources available online, but since it’s a bore to go looking for the right one (yes, some do not work), I figured let’s do it right once and document it so that it will always be there.

Create the keystore

Keystores are, guess what, files where your store your keys. In our case, we need to create one that will be used by both Tomcat and for the certificat generation.

The command-line is:

>keytool -genkey -keyalg RSA -alias blog.frankel.ch -keystore keystore.jks -validity 999 -keysize 2048

The parameters are as follow:

Configure Tomcat

Tomcat’s SSL configuration is done in the ${TOMCAT_HOME}/conf/server.xml file. Locate the following snippet:

<!--
	<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
           maxThreads="150" scheme="https" secure="true"
           clientAuth="false" sslProtocol="TLS" />
    -->

Now, uncomment it and add the following attributes:

• keystoreFile="/path/to/your/keystore.jks"
• keystorePass="Your password"

Note: if the store only contains a single entry, fine; otherwise, you’ll need to configure the entry’s name with keyAlias="blog.frankel.ch"

Starting Tomcat and browsing to https://localhost:8443/ will show you Tomcat’s friendly face. Additionnaly, the logs will display:

28 june 2011 20:25:14 org.apache.coyote.AbstractProtocolHandler init
INFO: Initializing ProtocolHandler ["http-bio-8443"]

Export the certificate

The certificate is created from our previous entry in the keystore.

The command-line is:

>keytool -export -alias blog.frankel.ch -file blog.frankel.ch.crt -keystore keystore.jks

Even simpler, we are challenged for the keystore’s password and that’s all. The newly created certificate is now available in the filesystem. We just have to distribute it to all browsers that will connect to Tomcat in order to bypass security warnings (since it’s a self-signed certificate).

Spread the word

The last step is to put the self-signed certificate in the list of trusted certificates in Firefox. For a quick and dirty way, import it in your own Firefox (Options -> Advanced -> Show certificates -> Import…) and distribute the %USER_HOME%"/Application Data/Mozilla/Firefox/Profiles/xzy.default/cert8.db file. It has to be copied to the %FIREFOX_HOME%/defaults/profile folder so that every single profile on the target machine is updated. Note that this way of doing will lose previously individually accepted certificates (in short, we’re overwriting the whole certificate database). For a more industrial process, look at the next section.

To go further:

• The Most Common Java Keytool Keystore Commands
• Tomcat 7 SSL Configuration HOW-TO
• Where can I download certutil.exe for Windows

Code review is part of my job, and you cannot know the crap I’ve seen. Like someone pointed out, it’s also sometimes the crap I’ve written

In all cases, however, it’s because some developers do not have deep knowledge of how things work: most learnt something (in university or from a senior developer) years ago and don’t challenge this information regularly though technology evolve. Others just google the problem at hand and copy-paste the first snippet in their environment.

This little article is basically a how-to describing the right way to get a handle on the manifest in the context of a web application. It seems easy but there are many ways to do it and as far as I know only one is the right way at this moment.

To begin with, one baaddd way to do it would be this:

InputStream inputStream = getClass().getClassLoader().getResourceAsStream("/META-INF/MANIFEST.MF");

Manifest manifest = new Manifest(inputStream);

Why so? Because dependending on your classloading strategy, you’ll fetch another manifest, that has nothing to do with the web application: for example, the above snippet will incidentally fetch the EAR manifest when using the default classloading strategy (Parent-First).

Another wrong code would be the following, for the same reason:

URL url = getClass().getProtectionDomain().getCodeSource().getLocation();

InputStream inputStream = url.openStream();

Manifest manifest = new Manifest(inputStream);

Finally, one could also try to get the war as a file, then read inside it: forget this path since we don’t know if the WAR will be wrapped in an EAR or deployed in exploded format (or not).

No, the only way (at the time of the writing of this post) is to use the API provided by an application server:

ServletContext application = getServletConfig().getServletContext();

InputStream inputStream = application.getResourceAsStream("/META-INF/MANIFEST.MF");

Manifest manifest = new Manifest(inputStream);

This is it: straightforward use of what a compliant application server gives us. Sources for a webapp example that display the version is included here in Maven/Eclipse format.

Servlet 3.0 is not only about the replacement of the web.xml deployment descriptor by annotations. In this article, we’ll see what improvement it makes in the realm of security.

In Servlet 2.5 (and before that), declarative security was about the following features:

• authentication method (BASIC, FORM, etc)
• authorization to differents parts of the application (web application resources)
• data confidentiality and integrity
• session time-out

Servlet 3.0 adds standardized ways regarding two configuration items.

The first parameter is how the session id is sent from the client to the server, so as for the latter to recognize the same session. Earlier in my carreer, I learnt that the first time an application server sends a response back to the client, it passes a cookie back and also appends to the URL, both referencing the unique jsessionid. Now, as soon as the second request is passed to the server, the latter knows the client accepts cookie or not and uses the appropriate mechanism: in essence, the strategy can be sumed up by “cookies first but fallback to URL rewriting if not possible”. Granted, there was a time when you couldn’t count on your client’s browsers to have cookies allowed. Nowadays, URL rewriting is first seen as a way to makes session hijacking easy as pie – even with HTTPS – since the id belongs to the URL. Hell, you’ll even find it in the logs! Servlet 3.0 aims to allow us to force the cookie strategy. The web.xml fragment to take care of this is the following:

<session-config>
  <cookie-config>
    <secure>true</secure>
  </cookie-config>
</session-config>

Moreover, cookies themselves can be unsafe since they can be accessed by most browsers JavaScript engine, thus allowing client code to read it. Yet, a subset of browsers let us configure the engine so as to disable JavaScript access (read and/or write) for this cookie. Servlet 3.0 let compliant application server mark cookies as HttpCookie, which does the trick. Even if this feature is completely implementation dependent, it helps cover a part of our security worries. It’s achieved with the nex web.xml snippet:

<session-config>
  <cookie-config>
    <http-only>true</http-only>
  </cookie-config>
</session-config>

Need for security are most often rediscoverd at the end of the development phase, when it costs much to implement. Moreover, some (if not most) securing nodes are a sysadmin’s responsibilities (configuring the 3rd-party LDAP, HTTPS, etc.). For example, the two previous capabilities were implementation dependent. This leaves security a very obscure field for young (and not-so-young) developers. I think that enhancements such as those provided by Servlet 3.0 tend to increase mutual understanding between developers and sysadmins.

Vaadin is available in version 6.6 preview since this week. Among other interesting enhancements, one surely caught my attention, the new Filter API.

To understand why it’s so interesting, one must know how it’s handled in version 6.5 and before. But first, a word about filters in Vaadin: they are used in containers, which handle collections of items, in order to sort out eligible items. The Container.Filterable interface define a method to add a single filter, whose signature is:

addContainerFilter(Object propertyId, String filterString, boolean ignoreCase, boolean onlyMatchPrefix)

So, we can only filter on string equality, and this equality can be loosened/tightened toward case and position. Morevoer, filters on the same property are additive. If you need to go beyond that, your goose is cooked. In a previous proposal to a request, the filter had to be accent insensitive, which is not supported. I had to hack like mad to implement it. In effect, since most of the container API’s code is private, I copied it to offer the needed option alternative. It did the trick but it’s pretty dirty.

However, the new API supplies a true extensible model for filters which renders my previous development obsolete. Facts worth mentioning are the following:

• The Container.Filterable interface becomes Container.SimpleFilterable, with no other changes in the method signatures
• A brand-new Container.Filterable is added, with the method:

addContainerFilter(Container.Filter filter)

• The Filter interface becomes public, and brings an entire hierarchy, with boolean composition in mind (meaning you can OR, AND or NOT you filters in combination). The interface has two methods:

appliesToProperty(Object propertyId)
passesFilter(Object itemId, Item item)

These updates make creating an accent-insensitive a breeze. Conclusion is, if you’re interested in Vaadin, you have to take a look at the new version, if only for the filter API!

To go further:

• Vaadin 6.6.0 pre1 is available here

The cloud is here to stay. When Google made Java available for its App Engine PaaS platform (before there was only Python), I was there and I tried it. Last week, VMWare launched its competitor, the CloudFoundry platform, and I wanted to try it the same way.

Since then, I’ve played a little with it and it’s full of good surprises compared to GAE. That is not to say that GAE was bad, in fact, it’s the first PaaS that is free under a certain trafic limit (and this limit is quite high) but it has some limitations that are really a burden for developers:

• First, if you need to persist your data (a likely event), you’re forced to use either JPA 1.0 or JDO with the DataNucleus datastore underneath. This means you can forget about NoSQL or MySQL or you preferred RDBMS. Moreover, you’ve to learn all about DataNucleus in order to configure the datastore. Since it’s not a widespread product (like Hibernate or EclipseLink), this can be quite a burden.
• Second, at every request, the entire session is serialized. This means a little overhead each time and possible NotSerializableException. I think (hope) this behavior has been corrected since I last used it, in order to only serialize when needed (that is when the user is directed to another server).
• Then, the term cloud is to be taken at face value: you see nothing of the infrastructure. No logs (although an interface let you see them, you can say goodbye to all your nicely log configuration), no configuration, no temp files, no nothing!
• Finally, you have only access to a subset of the Java API: no threads, no files, etc. The white list is available there: don’t be suprised by the high number, it’s quite few in fact. There are 1498 items, whereas the Java 6 API has 3793, meaning you have only 39% of all the features!

All these mean you cannot take an existing application, upload it to GAE and expect it to run like it ran on your local server.  In fact, migrating an application to GAE is a lenghty process, depending on the gap between what you use and what you are permitted to use. The worst is that once migrated, either you cannot run on a standard server anymore (or only in the GAE sandbox, which is provided) or it takes a very (very!) long time to configure both a GAE and a standard configuration.

The good news with CloudFoundry is that these limits don’t exist. I tried with two different applications:

• Twaattin, a custom application for my Learning Vaadin book based on Vaadin and HSQLDB. It also makes use of threads and files and heavily relies on the Twitter API.
• The Vaadin demo application available on their site, which I took and uploaded “as-is”.

Both deployed seamlessly on CloudFoundry from Spring Tools Suite. Moreover, the logs appear in the STS log tab, just like with any other local server. For example, I forgot to include SLF4J and was pleasantly surprised to see the stack informing me of that.

As for running the applications, it’s the same: they just run in the expected way out-of-the-box. In my STS, I can even see remote files! It’s a Tomcat instance, and I can read both its config files and the HSQL database files.

The whole thing is not even tied to Spring. Well, it sure helps. More specifically, it’s not trivial to connect to the offered database services without the Spring configuration but it’s possible (look here if you’re stuck). Until now, it’s the only negative point I’ve found.

Understand this: these are not production applications, I didn’t perform any performance testing (it’s forbidden by the terms of service anyway), beta doesn’t provide any billing information for the future and there’re no metrics displayed. Thus, my point of view is only from an developer perspective, who tried GAE 2 years ago. In this light, and until proven the contraty, CloudFoundry is a developer’s dream come true.

People interested in testing CloudFoundry for themselves and not taking my word for granted are welcome to do so (I would also like feedbacks). Requests for the service can be sent here. Alternatively, you can also get the source code on GitHub and deploy the CloudFoundry application on your own infrastructure.

Have fun!