Glassfish, Netbeans and JSF 2.0 Test Drive
I’ve spent some time in the last couple of weeks playing around with Glassfish, Netbeans 6.8 Beta (and milestone 2 before it) and JSF 2.0, and I have to say that this is turning out to be a really good set of development libraries and tools.
(note This post relates to both the milestone 2 and beta versions of Netbeans 6.8 which I have been tinkering with over the duration of this article being written.)
The download for Netbeans 6.8 comes with Glassfish v3 which implements JEE 6 including JSF 2.0 and JPA 2.0.
Glassfish now has really fast hot deployment so you can change a line of code, save it, and it re-deploys instantly which in my opinion, this is a huge productivity booster. This isn’t limited to Netbeans, the eclipse plugins also provide this feature, and it works with pretty much any framework. I tried it with Wicket and Spring MVC and it was fantastic to get a wicket error where I had forgotten to add a component, so I go back to the java page code, add the component, refresh my browser and it works. Glassfish now has support for JEE 6 so you can make a pojo a local EJB just by adding the @stateless
annotation to it. You can also deploy EJBs in war files as well without needing the whole EAR setup. One problem I did see was that when you used the EAR project setup with an EJB and War project, the hot deploy didn’t appear to work as well. Changes to the war file didn’t appear to redeploy, maybe because it is the EAR file that is deployed and not the war. However, still fantastic stuff.
Netbeans 6.8 beta was released in the last week or so. Feature-wise it is a great product with better tooling for JSF, including JSF 2.0, facelets support, and auto-completion for JSF backing beans in the JSF page. It also includes support for JEE 6, EJB 3.1, JPA 2.0 and development with Glassfish v3. It also improves upon the existing Maven support by providing for mavenized Ear projects.
While the features are impressive, Netbeans still seems hindered by performance issues and some minor bugs (although it is a milestone/beta release). Personally, I found this release no more sluggish that other releases although some people in the forums have had worse experiences. Netbeans strength has always been that it offers one standard solution without the plugin nightmares that eclipse has. While Netbeans has plugins they are more like installable features, they have a higher granularity than Eclipse plugins which is more like DLL hell. That said, I use Eclipse at work and it is always hard to shift from one keyboard mapping to another, and Eclipse does seem faster without the intermittent pauses. However, right now, Netbeans is a superior product in terms of features, especially for a JSF developer. I’d keep an eye out for the 6.8 final release to see how it comes out, and give 6.8 milestone 2 a go just to enjoy the experience if you are interested in using a standards based stack because thats obviously where the Netbeans folks are focused.
One big issue I have with Netbeans is the oddness of some of the key mappings. I think in nearly every application I use I press Alt+F and then C to close the currently edited document. Whether is it in MS Office, Borland Delphi, Eclipse, Firefox, while in the file menu, the C key always closes the currently open document you are editing. In Netbeans, it closes the currently edited project which means suddenly my project disappears when I want to close an edited file. Another is the use of Ctrl+Space for invoking auto completion which in Netbeans sends focus to the project manager or something like that. Sure, I can change the keymappings, such as to the Eclipse profile, but then I’m using some arbitrary weird key mapping which isn’t Netbeans and it isn’t completely the same as Eclipse. It is probably this way for legacy reasons, but some of these key presses are de facto standards.
Lastly, we come to JSF 2.0 which was forged from JSF 1.2 and the litany of complaints about it. The JSR group looked at the solutions out in the wild that already work around those problems (many of which were written by people in that very group) and incorporates those fixes in a standard JSF API type of way. Primarily we have the dropping of JSP as the default view in exchange for the Facelets / JSF templating solution. This also lent itself very well to easier component creation including no-code components. There is now zero configuration required except for the servlet in web.xml
and managed beans can now be defined using annotations. Navigation which also used to be in the faces-config.xml
is also more convention of configuration. Another big request was the inclusion of AJAX awareness in the JSF lifecycle . It provides the bare minimum features that 3rd party developers can build upon using the standard API instead of their own AJAX solutions. There is better support for GET requests and page parameters as well as invoking actions on page requests which is a feature often used in Seam.
There is also some performance boosts with regards to re-working state saving and the resource access mechanisms have been improved a great deal.
Also noteworthy is the inclusion of Weld CR 1 which is the reference implementation of JSR 299 – Java Contexts and Dependency Injection from JBoss. Admittedly, I haven’t really gotten round to taking a look at it, but from what I have seen and read so far, it looks like it fills some gaps in the JEE 6 platform and is up to par with the new found simplicity and strength that JEE 6 is promoting right now.
Overall, this is a pretty exciting set of tools and framworks and well worth a look if you are interested in adopting a standards based stack.