I honestly love jQuery javascript library, and absolutely am disappointed with JavaServer Faces (JSF).

jQuery is a neat library, that eases the javascript development, by enabling CSS (and other) search capabilities.

For instance if you want to change the background color to red for all items with the class “myClass” you just have to query $(".myClass").css("background", "red");.

I’m not going to go further on jQuery since there are a lot of tutorials out there. My problem was when I was trying to integrate jQuery with a JSF application. JSF as the neat “feature” of generating id’s for all our rendered components based on the view (or subview) which the component is on.

So if I have a <h:inputButton id="button1"/> the generated id will be view:button1. Which causes a main problem when you want to apply CSS styles to this element. You can’t simply add style to #view:button1 because it’s not CSS valid. And for making it worse, you can’t query using jQuery for this element to… so you see where I’m getting at.

The solution I found was to use the j4j Tag Library idProxy to generate a chosenidfor the components we want to manipulate via jQuery. The
j4j idProxygenerates an invisiblespan(I believe it’s label or a span element) with the id we wanted, and a title of the JSF generated id for our component.

So for our later inputButton we would replace with <h:inputButton id="button1"><j4j:idProxy id="myButton"/></h:inputButton> and get a
<span id="myButton" value="view:button1"></span&gt; right beside of our rendered inputButton component.

But still, this is not enough because if I want to manipulate via jQuery the input button we still have no way to access our component! So we need a javascript function, let’s name it jsf() which receive a <j4j:idProxy> generated code>id and returns our JSF component jQuery object!
function jsf(id){
//Finds the j4j Element and retrieves the ID of the target component which is stored on the
title attribute
realId = document.getElementById(id).title;

//Returns an jQuery element based on the DOM element of our target component
return $(element);
}

And voila! Now all we have to do to use jQuery on a JSF web application is to put the j4j:idProxy on every JSF component we want to manipulate and use the chosen id with the jsf() javascript function.

Just bumped into this article about Java on the Linux Desktop.

It seems that the Linux community is discovering that the open source Java platform is the ideal plaftorm for developing desktop applications for Linux. For me it’s an obvious choice considering that the other option is Mono (.NET).

Is Java (finally) becoming the dominant platform for desktop applications development?

One of the annoying things about developing for the web, is the whole cycle of writing code, compiling, deploying, running, debug, write code… etc.

So many development tools, help with this, by automatically exploiting the directory where our WAR was deployed and compiling directly to there. All JSP are copied “on write” to the same directory, and the developer as that warm feeling of never have to wait for a package to be redeployed again.

One way to accomplish this, is using Maven plugin for Jetty6. Just include the following plugin on your pom.xml under the plugins tag:


<plugin> <groupid>org.mortbay.jetty</groupid>
<artifactid>maven-jetty6-plugin</artifactid>
<dependencies>
<dependency>
<groupid>org.apache.geronimo.specs</groupid>
<artifactid>geronimo-j2ee_1.4_spec</artifactid>
<version>1.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<configuration>
<scanintervalseconds>10</scanintervalseconds>
</configuration>
</plugin>


After that, just type mvn jetty6:run and your project is automagically deployed on a new instance of Jetty6 which you can access on localhost port 8080. Of course, on the first time, Maven will download the required plugin and it will take a little longer.

If you set your IDE to compile directly to the target directory, the Jetty6 plugin will automatically detect any changes on your java classes, JSP, WEB-INF files, and reload automatticaly.

This plugin has been really helpful on developing web applications for Java here at RUPEAL.

Well… what if you have a group of two (or more) radio buttons and want to use the onchange event like this:

<input type="radio" name="xpto" value="One" onchange="onChangeHandler()" checked/>

<input type="radio" name="xpto" value="Two" onchange="onChangeHandler()"/>

When the onChangeHandler is fired up, which value is on our radio button form parameter “xpto” ? The old one? Or the new one?

It’s Just a matter of your web browser choice: If you use Firefox you’ll get the new value. But if you use Internet Explorer you’ll get the old one!

What about that?

For my case, where I wanted the new value, I’ve just starting using onclick and filter when the same value is selected.

Setting up a project with Hibernate Annotations using Maven2 is quite simple… or at least it should be. You should just have to set up your pom.xml file with the following dependencies:


<project>

...
<dependencies>
<dependency>
<groupid>hibernate</groupid>
<artifactid>hibernate-annotations</artifactid>
<version>3.2.1ga</version>
</dependency>
</dependencies>
...
</project>

And this is what I expected to start using Hibernate Annotations on my project. But if you try to compile your project you’ll get the following:


...
Missing:
----------
1) hibernate:hibernate-annotations:jar:3.2.1ga



Try downloading the file manually from the project website.

Then, install it using the command:


mvn install:install-file -DgroupId=hibernate -DartifactId=hibernate-annotations

-Dversion=3.2.1ga -Dpackaging=jar -Dfile=/path/to/file



Path to dependency:
1) ...
2) hibernate:hibernate-annotations:jar:3.2.1ga

…

So, Maven couldn’t resolve our dependency but at least gave us a hint on how to solve the problem. After downloading the Hibernate Annotations 3.2.1GA file and unzip it, we used the suggested command to solve the problem:

mvn install:install-file -DgroupId=hibernate -DartifactId=hibernate-annotations -


Dversion=3.2.1ga -Dpackaging=jar -Dfile=hibernate-annotations.jar

After successfully installing the package, the project successfully compiled!

The problem is that usually we don’t want to use Hibernate Annotations by itself, we want to use the Java Persistence API (JPA) which is included on the javax.persistence package. So by including another dependency on our pom.xml like this:

<dependency>
<groupId>javax.persistence</groupId>
<artifactId>ejb</artifactId>
<version>3.0-public_review</version>
</dependency>

we get a similar error as we did when we tried to use Hibernate Annotations. Maven can’t resolve the dependency, but this time it even give us a hint where to dowloand the missing library:

Missing:
----------
1) javax.persistence:ejb:jar:3.0-public_review

Try downloading the file manually from:

http://prdownloads.sourceforge.net/hibernate/hibernate-annotations-3.1beta5.tar.gz?download

Then, install it using the command:
mvn install:install-file -DgroupId=javax.persistence -DartifactId=ejb
-Dversion=3.0-public_review -Dpackaging=jar -Dfile=/path/to/file

If you notice, the URL where we can download the missing library is pointing to Hibernate Annotations! Since we already have downloaded Hibernate Annotations and it’s an earlier version than the suggested we just have to find out where the jar containing the javax.persistence is. And it’s on the ejb3-persistence.jar under the lib directory.

Issuing the installation command on the file, and you’re ready to go! Just type the following to install the jar on the local Maven repository:

mvn install:install-file -DgroupId=javax.persistence -DartifactId=ejb
-Dversion=3.0-public_review -Dpackaging=jar -Dfile=ejb3-persistence.jar

That’s it! Not so fun using Maven when the dependencies aren’t resolved “automagically” like the most, but it still is a fantastic tool for managing your Java projects!

Setting up a web project using Maven 2 is the simplest thing in the world. You just have to type in:


mvn archetype:create -DgroupId=groupId -DartifactId=TestWebapp -Dpackagename=your.package.name
-DarchetypeArtifactId=maven-archetype-webapp

Et voila! A new directory with your project name is created with the full directory structure of your web application. Lets take a look on what's inside of our project directory:

Directory structure

Inside our TestWebApp we can found our newly created pom.xml with a JUnit dependency already setup.

The rest of the structure is pretty intuitive. On src you'll find a directory with our main sources. Under this directory (src) we have resources where we put all properties and configuration files, webapp is where all files related with our web application goes (jsp, images, javascripts, stylesheets, etc.) including the WEB-INF stuff under the directory with the same name. The java files are under a directory that is not created initially by the archetype, but of course it's named java .

This archetype doesn't create our test directory, but it's pretty straight forward since it's same structure as main but it's named test (and also lives under the same directory src as we would expect to). To run our tests we just have to type mvn test.

After completing the structure by creating the java and test directory we have the following project structure:

Complete Directory Structure

To create the WAR file we just have to type in mvn package and all the maven life cycle phases run, including building all source files, resolving dependencies, testing and packaging our WAR file.

Running this command for the first time will take a little longer, since Maven needs to download all necessary files (including our project dependencies) to complete the requested task. On success, Maven will deploy our WAR file on the target directory under the root directory where all compiled classes are!

Simple isn't it?