Posts Tagged ‘Java EE’

Sample CRUD application with JSF and RichFaces

30 March 2012

During my thesis project I will be using JavaServer Faces. Therefore it is important I get familiar with the framework. To get familiar I made a small CRUD (Create Read Update Delete) application. It is a simple application that makes it possible to keep track of users. It consists of a user list, a page to add/edit users and a page to delete a user.

The code

The research project will focus on when it is beneficial to use client-side scripting instead of/complementary to server side programming. To get up to speed a small CRUD application has been made without the use of client-side scripting and the same CRUD application was adapted to use client-side scripting by using RichFaces. The client-side scripting was added to the editing form to allow validating the form, without the need of making requests to the server.

The structure of the source project is as follows:

  • backing
    • – Backing for index.xhtml
    • – Backing for UserDelete.xhtml
    • – Backing for UserEdit.xhtml
  • constraints
    • –  Validation annotation for fields. Fields with this annotation are validated to be a proper email address.
    • – Performs the validation for email addresses.
  • ejb
    • – Data Access Object for users.
  • entities
    • – Bean object for a user. The fields of this object are annotated with validators.
    • – Converts a userId to a user.
  • util
    • – Utility object that helps with sending messages between pages.

The following JSF pages are in the project:

  • index.xhtml – Page with a list with all users
  • user_delete.xhtml – Page used to confirm whether a user should be validated
  • user_edit.xhtml – Page used for adding and editing users

While creating this application, I tried as much as possible to adhere to best practices. For examples, to go from the master (list) view to the detail (edit) view a GET request is used with the user id as parameter. The user is modified via POST and there’s a redirect and GET back to the master view (PRG pattern).

Both applications make use of Enterprise Java Beans, Bean Validation and Java Persistence API. EJB is used to inject persistence in the managed beans. Bean validation is used to ensure the data is consistent with the business rules.

In the RichFaces version user_edit.xhtml is updated to have client-side validations. Only the email address cannot be validated on the client. For that field is Ajax used.

The code of the project has been uploaded to Google Code so it can viewed by everyone. The code without the use of client-side scripting is put in the default branch and the code with client-side scripting is put in the RichFaces branch.


The compiled applications have been uploaded to OpenShift. It makes showing your work to the public very easy. This is a free cloud platform which runs a JBoss server. The projects can be directly uploaded from Eclipse to the OpenShift server. The live demo can be viewed here.

To upload your project yourself to OpenShift it is first required to make an account at OpenShift. Then register your public key at OpenShift. When you have the OpenShift plug-in installed in Eclipse you can add the OpenShift server to the server view in Eclipse. From there you can get the default project from OpenShift. This project is only used to send the war files to server, not to hold the code. By adding the JSF project to the OpenShift server it automatically places the war file in the OpenShift project during a publish. By pushing the OpenShift project to the server using GIT, the application is put in the cloud and is ready to use. The detailed process to upload to OpenShift from Eclipse is available here.

So wrapping up, I’ve made a small project to get familiar with the code, I have uploaded the code to Google Code and I’ve put the application OpenShift.

Mark van der Tol

Jboss AS 5 GA released!

5 December 2008

Today is a historic day for Java, as one of the leading implementations of Java EE 5, Jboss AS 5 has *finally* been released. Originally planned for early 2007 orso and promised to be released almost every quarter.

But today, no more speculation and no guessing. It’s here, and this time it’s for real! Read all about this fabulous release here:

Download it from here:

With Jboss officially implementing the Java EE 5 spec now, a new baseline of Java has been set. From now on, technologies like JSF 1.2, EJB3 and JPA can really be considered as basic, standard available techs.

Congrats to the Jboss team, and hoping it won’t take them as long to release Java EE 6 😉


Jboss AS 5 GA release date

24 November 2008

People have been wondering for some time about the release date of Jboss AS 5. As many of you know, Jboss 5 has been in development for quite some time and its release has been highly anticipated. Arguably, Jboss is one of the most important, if not -the- most important Java EE implementation. The fact that an official release of version 5 of this spec has been so long overdue, has been painful. Of course, Jboss 4.2.x supports most of the Java EE 5 stuff, but it’s just not the Real Thing.

The importance of Jboss AS is due to a number of reasons. Of course there are other Java EE 5 implementations out there, but the number of offerings seem to be declining. On the commercial side of the fence there’s basically IBM’s Websphere and Oracle’s OC4J, and on the open source side there’s Glassfish, Geronimo and Jboss AS 5. For many people, a closed source, commercial Java EE implementation seems to be little attractive. This leaves us basically with only 3 options for the moment. Geronimo may be nice, but nobody seems to be using this. Glassfish should maybe be the default choice (afterall, the Sun Java SE implementation is typically the default choice for many too), but has two main problems:

  1. It can’t be configured.
  2. It doesn’t offer any services.

This basically leaves Jboss AS 5 as the only choice, it it weren’t for the fact that it was always still in beta or in rc. In a way, this left a kind of void in the Java EE world (unless of course configuration and services don’t matter to you, then I suppose Glassfish would be perfectly fine).

Previously, Jboss AS 5 had been announced for february 2008 (see Where is JBossAS GA 5), but this seemed to be too optimistic. A major milestone was reached when Jboss AS 5 RC2 was officially EE 5 certified. A careful guess for the GA release date was then made for early November 2008 (see JBoss AS is now EE5 certified!).

Today however, a definite date has been given by Project Lead Dimitris Andreadis:

December 2008!

(See Jboss 5 release date?)

For those interested, these are some additional interesting resources:

JSF 2.0, a glance

27 August 2008

Having been recently thrown into the deep waters of JSF and Facelets it seemed natural to do an evaluation of where this technology is going. JSF is currently at version 1.2. Version 2.0 is scheduled for release with Java EE 6. So what goodies will this bring us?

The main goals of the revision is to make development easier by integrating into the core system many tools/frameworks which were built on top of previous JSF versions. Ajax support, facelets-like templating, improved development support and better performance are all things that are mentioned in the specifications.

These are the highlights of what is coming:

I’m sure everyone is familiar with Ajax. JSF 2.0 includes Ajax in its life cycle and offers more direct support for its use. The view state can now be partially updated to reflect that only part of the view has changed. Ajax will make use of the new resource handler scheme. This isn’t very exciting in and of itself. A natural progression in the way one would expect this technology to mature.

Facelets is another technology needing to be incorporated into 2.0. Facelets allows us to define our pages in a different way by using XML and templating. The way to write these pages is very close to the the way we already work, which makes it easy to learn. The added usefulness of templating allows us to write less cluttered pages. It also increases code reuse. The popularity of this approach and its obvious usefulness make it inevitable that this would be included in JSF 2.0. This is currently referred to as ‘page description language’ in the JSF specification. While the name is less exciting than Facelets it is accurate and there is no doubt that this is a welcome addition to JSF

Development for JSF is getting some support through the ‘Project_Stage’ feature. This is no more or less than a context parameter. Now many people are excited by this, but I don’t quite seem to share the sentiment. Theoretically this will allow for actions dependent on where the project is in its life. Is it in production, unit test, system test or development? The options are limited, though probably enough. What I am wondering is what it is doing in JSF. While there is a use for a setting like this, indeed it seems common in many disparate projects, it seems to me to be a higher level setting than JSF level. JSF should support it, but not claim it.

Another interesting feature is the Resource Handler. Resources are anything that could be included in a component that is required for the component to be rendered correctly to the user-agent. Think about images, JavaScript or css files. The Resource Handler enforces a structure on your resources which in and of itself just helps in organizing your project. This will also make it easier for component developers. They know exactly where to put or look for resources without having to know what application is using them. Locale and versioning are handled automatically. Another advantage is that replacing resources runtime will be much cleaner. No restart of the system should be needed.

There are some things about resources I don’t like however. First of all the specification only specifies a structure for webapps. Implementations for other platforms are even invited to do whatever they want. It seems an unfortunate choice since you really want a standard to be standard. Another is the relocatable resource. Now you can tell certain resources where they are supposed to be. Put the tag in the body but tell it to be rendered in the head. I don’t understand the reasoning for this. Perhaps if it is based on some conditional programming elsewhere on the page….but quite frankly your page is probably getting to complicated at that point. If something needs to be in the head (body, wherever), just put it there. I wonder if I am not missing some essential insight with which I will all of a sudden see what a great and useful feature this is.

One argument for relocatable resource is that components may wish to write things in locations which are outside of their direct knowledge. The head of an HTML document is an example. A component, possibly called by other components, could decide it wanted to change the head of a document. This is completely undesirable behavior. If the component is generic it should never bother with anything outside its scope. If it isn’t generic then its use is limited anyway and one could ask why it is even a component. Thinking specifically of style information I would say that this should never be overwritten at component level. Scripts can be included in the body and shouldn’t require anything beyond what exists in the component anyway. Apparently the community desires this functionality. To me it seems a harmful construct which should not be supported.

All in all I think JSF 2.0 will be an improvement of the technology. It has listened and learned from what the community has built on top of JSF and incorporated the features that were most used. As well it improves its internal workings which is never a bad thing from a user perspective. While I may not yet understand all the choices made it is obvious that the changes were well thought out and planned. Assuming the implementation is improved as well then JSF 2.0 will be pretty much what you want from version 2.0.

Jasper Floor

useful links:

Ubuntu and Eclipse: The error was ‘BadAlloc (insufficient resources for operation)’.

19 January 2008

Linux and Eclipse have proved themselves as a killer combination for Java (EE) development. Specially for technology savvy users, which i guess a lot of programmers are, the combination is a dream come true.

Though once in a while things can heat up under the hood.

With the uprise of Ubuntu, meant as a very user friendly version of Debian, many developers are trusting in their Ubuntu/Java/Eclipse environment and with good reason. It installs very easily, runs very fast and provides features like update-notifications, very fast turn around times for security updates and an almost insane amount of hard and software support.

Though the common Linux distributions (may i even say OpenSource) practice of fast turn around on security updates is a very good thing to have. It can once in a while turn into an unpleasant experience. Like today 18 Januari 2008.

To fix a programming error in the Xorg graphical software component of Linux the Ubuntu people pushed out an update for it called xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1. I applied this update in the early morning when working at home and when i had to leave to continue working at the office i shutdown my laptop and went to the office as usual.

Only to find out that my laptop was not working as expected when booting up. The login manager appeared (GDM) and i logged in, finding my desktop (Gnome) in a half broken state. Firing up Eclipse was even worse, throwing me the following ‘unclear’ error message on the console:

The program ‘Eclipse’ received an X Window System error.
This probably reflects a bug in the program.
The error was ‘BadAlloc (insufficient resources for operation)’.
(Details: serial 1086 error_code 11 request_code 147 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the –sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Error Message

Now the obvious solution is to reinstall the package version before the security update or wait for the next update.

You can download the old version of the package from the following location:

Install this package with the following command

$ dpkg -i xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8_i386.deb

Now restart your X server by loggin out of your desktop and back in again or restarting your server and you should be fine again.

At the time of writing, which is about half a day after the update hit the Ubuntu servers and i first found myself dealing with this problem, the Ubuntu people are pushing out there second update for the broken xserver-xorg-core package called: xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.2

You can safely install this new version and have everything working as expected.


Old good version:


Broken updated version:


New good version:


If you want to be safe, wait until tomorrow (19/20 Januari 2008) before you hit the update button, make sure that you updated your apt repository and verify that it’s installing the 8.2 update version of xserver-xorg-core. Then you should be all set to keep your desktop up to date and running like a charm 🙂

Last but not least, the official advisory for this bug:

Debian Security Advisory DSA-1466-2
Package : xorg-server, libxfont, xfree86
CVE Id(s) : CVE-2007-5760 CVE-2007-5958 CVE-2007-6427 CVE-2007-6428 CVE-2007-6429 CVE-2008-0006

The fix for CVE-2007-6429 introduced a regression in the MIT-SHM
extension, which prevented the start of a few applications. This update
fixes this problem and also references the patch for CVE-2008-0006,
which was included in the previous update, but not mentioned in the
advisory text.

Ing. Bas van Oostveen


Post-Scriptum: currently Ubuntu has released even a third patch to xserver-xorg xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.3

css.php best counter