Android Hardware Debugging from Ubuntu in VMWare

Some time back, I had posted an article on Android hardware debugging from Windows. The process is much simpler in Mac OS X or Ubuntu Linux. There, you don’t need to install any special device drivers. Today, I managed to connect my HTC Thunderbolt to Ubuntu 12.04 running as a VMWare guest. The process was simple and worked the first time. Here are the basic steps. I use VMWare Player. I assume the steps will be almost the same for VMWare Workstation.

These steps assume that you have a basic Ubuntu workstation working as a VMWare guest. Log into Ubuntu as the administrator user and then carry out these steps.

Step 1 – Install JDK and Android SDK

You will need Oracle JDK installed. Just download the distribution and unzip it somewhere. Then add <JDK>/bin folder to your PATH. If you are not sure, follow this guide.

Go to and download the SDK for Linux. Extract it somewhere, say within your Documents folder. In my case, this created the ~/Documents/android-sdk-linux folder. I will refer to this folder as <SDK> from now on.

Step 2 – Download SDK Platforms

From a command prompt, go to <SDK>/tools. Run this command to open the SDK manager.

./android sdk

Download the version of Android platform that is right for your phone. For example, my phone is running Android 2.3.4. So, I downloaded the nearest Android SDK 2.3.3.

For more information on downloading SDK platforms, read Google’s official guide.

Step 3 – Configure udev

udev is the Linux dynamic device management software. We will need to register our phone as a USB device.

From the command prompt, go to /etc/udev/rules.d folder.

Create a file in that folder called 51-android.rules as follows.

sudo vi 51-android.rules

In that file, I entered a single line for my HTC Thunderbolt.

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="mygroup"

In your case, you will need to enter a different vendor ID (0bb4 is for HTC) and UNIX group that will own the device. For a list of vendor IDs and more information read the official hardware debugging guide.

Then, give read permission to the file for everyone.

sudo chmod a+r 51-android.rules

Step 4 – Plug in the Phone

Before you plugin your phone, enable USB debugging (Settings > Application > Development > USB Debugging).

While the VMWare guest window is in the foreground, plug in the phone to a USB slot. VMWare should automatically connect the guest with the device. Note: a device can be connected to either a guest or the host but not both. The fact that VMWare connected the device to the guest by default saved me a lot of trouble.

Step 5 – Test Connection

From the command prompt, go to <SDK>/platform-tools. Then run this command:

adb devices

Make sure that your phone is listed.


Configure JDK Logging in JBoss AS 7

I personally prefer logging using JDK logging API (java.util.logging package). It’s darn easy to use and comes with the JDK. IBM’s WebSphere was the first app server to switch to JDK logging. Now, JBoss 7 is also integrated with it. When developing, I need to bump up the log level to FINE. In this article, I will explain how to do that.

A typical class doing logging will look like this.


public class TestBean {
    Logger logger = Logger.getLogger(getClass().getName());
    public void someMethod() {
        logger.fine("someMethod() called");

Note, we use the class name as the log category name. This is the best practice. This helps us configure log level for the whole package.

In JBoss 7, logging is configured using the domain file (standalone.xml or domain.xml). During development using Eclipse JBoss Tools, we use the standalone profile. So, open the file <JBOSS>/standalone/configuration/standalone.xml. Locate the logging subsystem. It starts from this line:

<subsystem xmlns="urn:jboss:domain:logging:1.1">

Configure the log level for your Java package by adding these lines to the subsystem. This will set the log level to FINE.

<logger category="">
 <level name="FINE"/>

You will also need to increase the log level for the console handler. Only then the low priority messages will show up in Eclipse Console view. Change the log level as shown below.

<console-handler name="CONSOLE">
 <level name="FINE"/>
   <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>

Save and close the file. Restart the server for the changes to take effect. That’s it. Now, low priority log messages from your code will start to show up in the console.

JSF Page Rendering After Validation Failure

The way JSF components render themselves depends on if validation had failed or not. This article will explain this subtle difference in behavior.

Consider the simple managed bean:

public class Controller {
    Logger logger = Logger.getLogger("TestWeb");
    private String name;
    private int age;

    public String updateCustomer() {"Updating " + name);

        return null;

    public void prepareRender() {
        name = "Please enter a name";
        age = 0;
    //getters and setters...

And the view:

    <f:event listener="#{controller.prepareRender()}" type="preRenderView"/>

<h:messages />
  Name: <h:inputText value="#{}"/><br/>
  Age: <h:inputText value="#{controller.age}"/><br/>
  <h:commandButton value="Update" action="#{controller.updateCustomer()}"/>

Lifecycle After Valid Input Submission

Let us say that a user enters valid input (name: John Smith, age: 12) and submits the form. The lifecycle of the request will go as follows.

1. Restore View Phase – This phase completes as usual. Nothing special to discuss.

2. Apply Request Values Phase – User’s input is collected from the POST request parameters and stored with each UI component. Since all inputs are valid, no conversion error occurs at this point and no error message is queued.

3. Process Validation Phase – Each UI component validates the input. Since all inputs are valid, no error message is queued.

4. Update Model Values Phase – In this phase, the name and age properties of the Controller managed bean are updated with the user’s input as it was stored by the UI components in phase #2. As a result, name becomes “John Smith” and age becomes 12.

5. Invoke Application Phase – In this phase, the updateCustomer() method of the managed bean is invoked. The log message prints out the name as “Updating John Smith”.

6. Render Response Phase – First, the prepareRender() method of the managed bean is called, since, it is setup as a pre-render listener. This method resets the model properties. For example, name is set to “Please enter a name”. Next, each UI component renders itself. They grab the data to be output from the model. This is the crucial fact and will play a role later. So, the name text box shows “Please enter a name” and the age text box shows 0.

Lifecycle After Invalid Input Submission

Let us say that a user submits invalid input. Let’s consider two cases:

Case #1: Name is left empty. Age is 12.
Case #2: Name is “John Smith” and age is “abc”.

The lifecycle of the request will go as follows.

1. Restore View Phase – This phase completes as usual. Nothing special to discuss.

2. Apply Request Values Phase – User’s input is collected from the POST request parameters and stored with each UI component. Some invalid input can cause conversion failure. For example, in case #2, conversion will fail for the age text box. In that case, an error message will be queued. Note, a UI component will store input value even if conversion fails. So, in case #2, the age text box component will store “abc”. Lifecycle will proceed to the next phase, even if there was a conversion error.

3. Process Validation Phase – Each UI component validates the input. In case #1, validation will fail for the name text box. For each validation rule violation, an error message is queued.

4. Update Model Values Phase – Since, either conversion or validation had failed, this phase will be skipped. So, the name variable of the managed bean will remain null. And, age will remain 0.

5. Invoke Application Phase – Since, either conversion or validation had failed, this phase will be skipped.

6. Render Response Phase – First, the prepareRender() method of the managed bean is called. This will set the name variable to “Please enter a name”. Next, each UI component renders itself. Now, here is the twist. Instead of grabbing the data to be output from the model, the components will use the input that they had saved in Apply Request Values phase. That means:

For case #1: Name will be empty. Age will be 12.
For case #2: Name will be “John Smith”. Age will be “abc”.

Note, at the time of rendering, the name property is set to “Please enter a name” and age is 0. But, the UI components will ignore that and instead render the actual input entered by the user. So, the work done by prepareRender() is completely wasted. In real life, if the pre-render listener does any kind of database query, you may want to optimize that by skipping the work incase of a validation or conversion error.

public void prepareRender() {
    if (FacesContext.getCurrentInstance().isValidationFailed() == false) {
        name = "Please enter a name";
        age = 0;

Paginated List in JSF 2.0

Pagination is the recommended pattern when you have a very large list to display. This reduces network I/O from the database and the web server. It may also reduce disk I/O in the database, although that depends on the database and several other factors.

Starting with JSF 2.0, the right and easy way to implement pagination is using GET request. As a general rule, you should avoid POST for any request that renders HTML. POST is used for display generation only if you need AJAX support. That’s because, in JSF 2.0, AJAX is supported for POST requests only.

In this article, I will explain how to implement pagination using GET request. I will write another article that shows how to do pagination using POST and AJAX.

The Managed Bean

The managed bean needs to keep track of the start index of the page. It will look something like this.

public class Controller {
  List<UserBean> userList;
  int startIndex=0, pageSize=10;
  public List<UserBean> getUserList() {
    if (userList == null) {
    return userList;
  public void loadUserList() {
    //Fetch paged data from the database
    userList = dao.getAllUsersPaged(startIndex, pageSize);
  //Various getters and setters omitted for brevity

The View XHTML

Let’s say that you are rendering a list as follows:

    <f:viewParam name="startIndex" value="#{siteAdmin.startIndex}" />
    <f:event listener="#{siteAdmin.loadUserList()}" type="preRenderView"/>

<h:link outcome="user_list" value="Previous">
  <f:param name="startIndex" value="#{mbean.startIndex - mbean.pageSize}" />
<h:link outcome="user_list" value="Next">
  <f:param name="startIndex" value="#{mbean.startIndex + mbean.pageSize}" />
   <th>Name</th> <th>E-mail</th>
 <ui:repeat value="#{mbean.userList}" var="user">
   <td>#{}</td> <td>#{}</td>

In the XHTML page, first study the metadata section. We can manipulate the startIndex property of the managed bean by sending a startIndex URL parameter.

When next or previous navigation link is clicked, a GET request will be sent. The startIndex URL parameter will be added. For example: “user_list.xhtml?startIndex=10”. JSF will first update the startIndex property of the managed bean from the value in the URL parameter. It will then call loadUserList() since that is the pre-render listener. This method will then load the correct page of the list since startIndex has been already modified.

Now, all there is left to do is disable Next and Previous links depending on if you are already on the first or last page. This is actually quite easy. I will leave a few hints:

  • Disable Previous link if mbean.startIndex is 0.
  • Disabling the Next link is a little more complicated. When requesting data from the database, ask for one more row than the page size. If the returned number of rows is more than or equal to the page size, then you know that there is no more items left.

This solution using GET request will perform well. We do not store the managed bean in session or view scope. This lowers memory requirement.

Defining Join Column Property in JPA

With JSF 2.0, EJB 3.1 Java EE has become easier to code than ever. However, JPA relationship remains a thorn in my shoes. I find it counter intuitive and just plain difficult to work with. Today, I will talk about a specific issue.

Consider two related JPA entities Employee and Organization. Employee has an unidirectional many-to-one relationship to Organization.

public class Employee {
 private int id;
 private String name;
 private String phone;
 //uni-directional many-to-one association to Organization
 private Organization organization;
 //Getters and setters omitted...

public class Organization {
 private int id;
 private String logo;
 private String name;
 //Getters and setters omitted...

And the schema (MySQL in this case):

CREATE TABLE Organization (
 name varchar(128) DEFAULT NULL,
 logo varchar(128) DEFAULT NULL,
 UNIQUE KEY OrganizationU1 (cn),
 name varchar(128) NOT NULL,
 phone varchar(45) DEFAULT NULL,
 organizationId integer DEFAULT NULL,
 CONSTRAINT UserRegistryFK1 FOREIGN KEY (organizationId) 
  REFERENCES Organization (id)

This works just fine. But, I have a bone to pick. The Employee entity doesn’t have a property defined for the organizationId column. To get the organization ID, we have to load the organization and then get the ID from there.

Employee employee = em.find(Employee.class, id);
int orgId = employee.getOrganization().getId();

This seems wasteful. (In many-to-one, eager fetching is used by default. So, the code above will use a single SQL statement to load both employee and organization. Still, that is wasteful, if the Organization table has large rows).

Another problem appears when we need to create a new employee. Since, there is no way to store the organization ID within the Employee object, we must pass it separately to the DAO class:

public void addEmployee(Employee e, int orgId) throws Exception {

This is just messy. Things will be a lot cleaner if we could store the organization ID directly within the Employee entity. As it turns out, this can be done.

public class Employee {
 //Existing code omitted...
 @Column(name="organizationId", insertable=false, updatable=false)
 private int organizationId;

Basically, we are adding the organizationId property like any other mapped property. Except, we must set insertable and updatable to false. We need to do that because for insert and updates involving relationship, the related object property is used during persistence. In our case, that will be the Organization property of the Employee.

For example, now, our insert logic becomes cleaner.

public void addEmployee(Employee e) throws Exception {

Also, now, we can employ lazy loading and get the organization ID of an employee without loading the Organization.

On a side note, it just pains me to have to load the Organization before I can insert an employee. There is absolutely no business case for it. Not only is this unnecessary coding, it also adds load on the database for no good reason. For now, I will live with this to get the “convenience” of ORM.

Display JSF Error Messages Using Custom HTML

By default JSF messages are shown using <h:messages/> tag. This includes form validation error messages. This tag shows messages in a simple bulleted list using <ul> and <li>. For example:

<li>Please enter a phone number</li>
<li>Please enter a valid e-mail address.</li>

However, if you wish to show messages using custom HTML layout and additional instructions, <h:messages> will not be useful. The code below shows all error messages (severity level 2) using custom HTML:

<h:panelGroup rendered="#{facesContext.maximumSeverity.ordinal == 2}" 
 <p>Please fix these problems:</p>
   <ui:repeat var="msg" value="#{facesContext.messageList}">

Note, JSF doesn’t say anywhere that the error level messages have an ordinal of 2. This may change from implementation to implementation.

Similarly, to show informational messages, you can do:

<h:panelGroup rendered="#{facesContext.maximumSeverity.ordinal == 0}"