SolitaryGeek » Java

Wicket: Serving static files

James — Mon, 06 Dec 2010 08:07:00 +0000

I recently came across a situation where I have to serve some static html files in a wicket application. Though it’s pretty simple, thanks to the ultra easy way wicket offers to write components, things can get tricky especially with the request path.

So I thought of documenting this for my own future reference and for the sake of the community.

Without wasting time, let me quickly explain how to serve static files with wicket (blatantly copied from wicket-examples).

Assumptions

I assume that you are using wicket 1.4.x as that’s the latest stable version at the time of writing this post.

Component

First let us write a reusable component class called “StaticLink”.

private class StaticLink extends WebMarkupContainer {
public StaticLink(String id, IModel model) {
super(id, model);
add(new AttributeModifier("href", true, model));
}
}

Html

In the html file where you want to put this link, add something like this:

 My static link

Java

In the respective java file, all you need to do is this:

String contextPath = RequestUtils.toAbsolutePath(RequestCycle.get().
     getRequest().getRelativePathPrefixToWicketHandler());
add(new StaticLink("myStaticLink", new Model(contextPath + "docs/index.html")));

Here were are resolving the absolute url of the static page which will free you from the hassles of using a relative url especially for static pages. The “contextPath” which we are constructing here will have the trailing “/” so you need not add it.

Extracting only date part of a date time column using JPA/Hibernate

James — Mon, 11 Oct 2010 10:41:00 +0000

I recently came across a situation where I have to get only the date portion from a column whose data type is “timestamp” (which is mapped using @TimeStamp annotation). After hours of investigation, I found a way to do that using standard jpa/hql queries and hence thought of documenting it in this post.

MySQL has a simple “date() function” that would just give the date part from a date time expression. Microsoft SQL Server offers a couple of ways to achieve the same. Unfortunately, I couldn’t find any standard ways provided by jpa/hibernate to achieve this.

Interestingly, the closest thing that can be considered as “standard” is the “cast function” which many databases seem to support. This prompted me to go for this solution because I felt this might be clean, as the syntax across different databases are pretty much similar.

So I came up with a query something similar to this:


select cast(myDateTimeColumn as date) from MyTable

This worked flawlessly on MySQL! Great..!

But, I quickly ran into problem when hibernate executed the same jpl/hql query against Microsoft SQL Server. Hibernate acted a bit smart and generated the following query (trimmed for clarification):


select cast(myDateTimeColumn as dateTime) from MyTable

That’s not what I expected! That defeats the purpose of the “cast” function itself

Why the heck Hibernate does this weird stuff? I thought of digging deep to learn more about this behaviour of Hibernate.

Hibernate uses the “CastFunction” class to handle “cast” functions you write in your queries. Upon exploring the class, you will find that this is how the “cast” functions are interpreted,

 return "cast(" + args.get(0) + " as " + sqlType + ')';

Where the “sqlType” is determined as follows:

 String sqlType = factory.getDialect().getCastTypeName( sqlTypeCodes[0] );

Hibernate stores the type names in a hash map and by default, registers the “Date” type as “datetime” like this:

 registerColumnType( Types.DATE, "datetime" );

And that is exactly the reason for the weird behaviour I mentioned in the SQLServerDialect.

Fortunately, hibernate provides hooks to tweak the dialects to support the features that are not otherwise available by default. All we need to do this is to write a custom dialect class by subclassing the appropriate dialect. This is the custom sql server dialect class that I came with:

 package org.hibernate.dialect;

import java.sql.Types;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;

/**
 *
 * @author James Selvakumar
 */
 public class CustomSQLServerDialect extends SQLServerDialect
 {
 private static final Logger logger = LoggerFactory.getLogger(CustomSQLServerDialect.class);

@Override
 public String getCastTypeName(int code)
 {
 String castTypeName = "";
 if (code == Types.DATE) {
 castTypeName = "date";
 } else {
 castTypeName = super.getCastTypeName(code);
 }
 logger.debug("Code: {}, cast type name: {}", code, castTypeName);
 return castTypeName;
 }
 }

That’s pretty simple, wasn’t it? We are playing safe here by overriding only the “getCastTypeName” method and returning the cast type name as “date” when the type is Types.DATE. We are delegating the responsibility to the super class for “getCastTypeName” requests other than Types.DATE.

Just update your hibernate configuration to make use of this dialect for sql server datasource.

Fortunately, this solution worked flawlessly for me on both MySQL 5.1 and Microsoft SQL Server 2008 databases. It didn’t work though with HSQLDB 1.8.

I hope this helps some of you. If you find any issues in this article or have any other great idea, consider sharing that in the comments.

NetBeans and Maven – A quick start guide

James — Sun, 26 Sep 2010 07:30:22 +0000

A few months ago, I was reading the book “Wicket in Action”. I was new to Wicket and Maven then. I followed the instructions given in the book to create a maven project. The book went one step further and explained how to create eclipse and idea projects from the pom, but nothing was mentioned about NetBeans. I felt sad that there is no maven plugin out there to create projects that NetBeans can understand.

But later when I realized that there is no such need to create Netbeans projects from Maven pom, I was thrilled. Maven, is a first class citizen in NetBeans. Any Maven project “is a” NetBeans project.

Over the months, as I continued to learn and use Maven, NetBeans made the the learning curve easy. So I thought of putting up this post to benefit new Maven users.

Setup

If you are using Maven for the first time, you may want to download and install it on your machine.

Though NetBeans comes with an embedded Maven instance (version 3.0-SNAPSHOT in NetBeans 6.9 at the time of writing this post), it’s still a good idea to have your own Maven instance, so that you can use it outside the IDE as well.

Installing Maven is quite easy. Download the latest Maven distribution (version 2.2.1 at the time of writing) and follow the installation instructions for your operating system.

Now, let’s quickly dive into action by firing up the IDE and create a new Maven project.

Creating a new Maven project

Open NetBeans IDE and click “File -> New Project” and then choose “Maven” as the category and “Maven Project” as the project type.

In the next step, select “Maven Quickstart Archetype” as the maven archetype.

Finally, enter other details of your project and finish the wizard.

That should leave you with a new Maven project with a structure similar to this:

One thing I like about NetBeans is that it always gives you some workable defaults whether it’s a web project or a simple java project.

No difference here. Just right click the java source file the IDE generated for you to watch your Maven project in action.

And this is the default “pom.xml” the IDE generated for you:




4.0.0
examples.maven
hellomaven
jar
1.0-SNAPSHOT
hellomaven
http://maven.apache.org



junit
junit
3.8.1
test

If you know Maven already, you know what’s happening. Even if you are new to Maven, there is nothing to worry. Every Maven project needs a few mandatory definitions and that’s what you are seeing now.

Improving the default project

There are a couple of things we can improve in this project. First let us cleanup the “pom.xml”. As you can see, a depedency to junit 3.8.1 has been declared in the pom. That’s pretty archaic and let us change the junit version to the latest available version.

You need not scratch your head to figure out what’s the latest version of junit. The IDE is right there to help you. Keep the cursor near the version element and invoke the code completion by pressing the appropriate key. (In my case it’s CTRL + SPACE). Now, the IDE should give you a list of available junit versions in the default Maven remote repository.

Choose the latest available junit version and save the details.

Let us rewrite the test case making use of the recent junit enhancements. Delete the existing unit test class and create a new one by right clicking the java source file and then selecting “Tools -> Create Junit Tests”. You should see the IDE displaying a dialog saying that it cannot create junit 4.x tests.

There is nothing wrong with the IDE here. Because JUnit 4.x makes use of annotations and hence need a Java source level of 1.5 or above. By default, Maven doesn’t assume your source files to be 1.5 compatible, so you need to tell Maven exactly what Java source version you would be using in your projects. Doing that is quite simple. Open the project’s “pom.xml” in the editor and define the Java source level like this.




4.0.0
examples.maven
hellomaven
jar
1.0-SNAPSHOT
hellomaven
http://maven.apache.org



junit
junit
4.8.1
test






org.apache.maven.plugins
maven-compiler-plugin

1.6
1.6

You should be able to create JUnit 4.x tests from the IDE now.

Applying “Test Driven Development” to our project, let us create an unit test for an non-existent method in the java source.

And now write the actual method in the java source so that the IDE doesn’t complain about the errors in our unit test.


protected String sayHello(String input)
{
String output = "Hello " + input;
return output;
}

Go back to the unit test and run it.(I usually type CTRL + F6 to run the unit tests). Congrats! Your Maven project is seriously ready for prime time.

Do not take me wrong but it’s really a good practice to write unit tests for everything and that’s why I bothered you with this stuff.

Don’t use System.out.println!

Though we are already familiar with dependencies, we only used JUnit which is a test dependency. And this is a good time to dive into the dependency hell by introducing our next dependency to this little project, “slf4j” or “Simple Logging Facade for Java”.

It’s hard to imagine any project without “logging” and our example project is no exception. (Heck, what’s there to log in this project???)

And with “slf4j” gaining wide spread adoption, let us make use of it. “slf4j” doesn’t tie our application to any logging framework (other than itself ). It’s something like “jpa”. It gives you the freedom to choose your own logging provider. (My current favourite is logback)

Enough talking, let us starting using logging in our project.

To justify the use of logging, let us create some opportunity by updating our “main” method.


public static void main(String[] args)
{
if(args != null && args.length > 0)
{
System.out.println(new App().sayHello(args[0]));
}else{
System.out.println("You have to pass atleast one argument to get a warm response from me!");
}
}

Time to fix those “System.out.println” calls by using slf4j. Create a slf4j Logger instance.

That’s obvious. By no way the IDE can figure out what is happening here apart from resolving the “Logger” to java.util.logging which is not our objective.

Now click the edison’s bulb in the gutter to see what magic the IDE has under it’s hat.

Select the option “Search Dependency at Maven Repositories…”. The IDE should popup a window with the possible matching artifacts.

Scroll to the bottom and locate “slf4j-api” and click “Add”. This will add the latest version of slf4j-api as a dependency. If you want to be more specific on the version, you can expand the slf4j-api node and choose the appropriate version.

Go back to your “pom.xml” and see a new dependency for “slf4j-api” has been added. If you don’t want all this hassle, you can straight away add the following snippet in your pom.xml to add a dependency for slf4j-api.



org.slf4j
slf4j-api
1.6.1
jar

Fix your imports in the source file and you are set to use slf4j.

Now change the reference to “System.out.println” with appropriate logging calls.


public static void main(String[] args)
{
if(args != null && args.length > 0)
{
logger.info(new App().sayHello(args[0]));
}else{
logger.warn("You have to pass atleast one argument to get a warm response from me!");
}
}

Run your main class to ensure that everything is fine.

That’s not we expected. Nothing is logged! There is nothing wrong with this phenomenon as we haven’t defined any logging provider yet. Remember, slf4j is just a specification.

Okay, it’s time to add a logging provider and with all the bias let us choose “logback” for this purpose. (Please feel free to use your preferred logging provider.)

Slf4j has a bunch of adapters for popular logging frameworks like “log4j” and “jul” (java.util.logging). (Please don’t raise flame wars by asking whether “jul” is really popular!)

If log4j is your cup of tea or coffee, please go ahead and check the slf4j manuals for further reference.

I’ll use “logback” for this example and let us add the dependencies for that now. Right click the “Libraries” node of your project and click “Add Dependency”.

The IDE should popup a window now where you can search the dependencies you want to add by typing the respective name in the “Query” field.

To use logback in your project, you need to add the dependency “logback-classic”. (This will automatically add the transitive dependency “logback-core”)

Expand the respective node, choose the version you want and click “OK” to add them to the project.

You can see the added dependencies in the “Libraries” node of the project.

Again, if you are not a big fan of wizards, you can drop in the following snippet in the pom.xml straight away.



ch.qos.logback
logback-classic
0.9.24

That’s it. If you run the main class now, the logging calls should be negotiated properly.

To remove a dependency, you can either right click the respective dependency in the “Libraries” node and then click “Remove dependency” or edit your pom.xml and delete the respective reference to the dependency. It’s upto you.

To keep this post live up to it’s title, I’ll not discuss the tons of other Maven related stuffs NetBeans has. I’ll probably cover some of them in a later post.

For the sake of completeness, here is the final pom.xml:




4.0.0
examples.maven
hellomaven
jar
1.0-SNAPSHOT
hellomaven
http://maven.apache.org



junit
junit
4.8.1
test



org.slf4j
slf4j-api
1.6.1
jar



ch.qos.logback
logback-classic
0.9.24






org.apache.maven.plugins
maven-compiler-plugin

1.6
1.6

And the java source file:


package examples.maven.hellomaven;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
* Hello world!
*
*/
public class App
{
private static final Logger logger = LoggerFactory.getLogger(App.class);

public static void main(String[] args)
{
if(args != null && args.length > 0)
{
logger.info(new App().sayHello(args[0]));
}else{
logger.warn("You have to pass atleast one argument to get a warm response from me!");
}
}

protected String sayHello(String input)
{
String output = "Hello " + input;
return output;
}
}

The Junit test class:

package examples.maven.hellomaven;

import org.junit.Test;
import static org.junit.Assert.*;

/**
 *
 * @author james
 */
public class AppTest
{
 public AppTest()
 {
 }

 @Test
 public void testSayHello()
 {
 App app = new App();
 String input = "Maven";
 String expected = "Hello " + input;
 String result = app.sayHello(input);
 assertEquals(expected, result);
 }
}

As you have seen above, NetBeans offers great support out-of-the-box for Maven. No plugins required. If you are not a NetBeans user but use Maven, I recommend you to give it a try. You’ll not be disappointed.

Thanks for reading patiently and please leave your comments if you have any.

What Java Look and Feel do you use?

James — Mon, 09 Nov 2009 15:10:32 +0000

Quite some time back, I read an article titled “20+ Free Look and Feel Libraries For Java Swing“. I have evaluated most of the libraries mentioned in that article. Personally, I prefer the System look and feel that is bundled in the JRE. However, I like Substance, PGS and JGoodies as well. Which one do you use? Curious to know.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Developing A Simple Java Application With Spring

James — Tue, 03 Nov 2009 16:12:23 +0000

Introduction
Spring is a powerful application framework that can be used across any layer in your application. For example, you can use Spring to manage only your data access layer or you can use Spring to provide remote services for your swing client. In this article, I will explain how to get started with Spring by developing a simple java application.

Requirements
1. Your favorite IDE
2. Latest Spring framework.

(Note: This article makes use of Spring framework 2.5.6 which is the current production release)

The Application
We are going to develop a simple application that fetches and display the list of registered users. The application consists of just two interfaces, their implementation.

The DAO layer
Let us now develop the DAO layer of the application. This layer consists of just one interface “UserDao” and it’s implementation “UserDaoImpl”. The interface consists of just one method named “getUsers()”. Let us quickly develop them.

Listing 1. UserDao

package com.springapp.dao;
import java.util.Iterator;

/**
 *
 * @author James
 */
public interface UserDao
{
    Iterator getUsers();
}

Listing 2. UserDaoImpl


package com.springapp.dao;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

/**
 *
 * @author James
 */
public class UserDaoImpl implements UserDao
{
    public Iterator getUsers()
    {
        List users = new ArrayList();
        users.add("Gavin King");
        users.add("Geertjan");
        users.add("Mike Keith");
        users.add("James");
        return users.iterator();
    }
}

Nothing fancy here. The implementation is pretty straight forward, though in a real environment you might fetch those details from the database using ORM frameworks like JPA.

The Service Layer

We will encapsulate the service layer from the dao implementaion by writing code against the interface UserDao. We will follow the same pattern we used in developing the dao layer and write the interface UserService and it’s implementation UserServiceImpl.

Listing 3. UserService


package com.springapp.service;

import java.util.Iterator;

/**
 *
 * @author James
 */
public interface UserService
{
    Iterator getUsers();
}

Listing 4. UserServiceImpl


package com.springapp.service;

import com.springapp.dao.UserDao;
import java.util.Iterator;

/**
 *
 * @author James
 */
public class UserServiceImpl implements UserService
{
    private UserDao userDao;

    public Iterator getUsers()
    {
        return userDao.getUsers();
    }

    public void setUserDao(UserDao userDao)
    {
        this.userDao = userDao;
    }
}

Kindly notice that both the service layer classes and dao layer classes are Spring agnostic. That’s the beauty of Spring. Spring is less invasive. Most of the application code can be developed without knowing anything about Spring.

The Client

Now we need someone to make use of our service layer and we will waste no time in developing the client for our service. We can just write a junit test class to invoke our service but I prefer to write a simple java class to be the client. Though our client will be a simple POJO class, you can easily replace it with a Swing or Web front end. Enough talking, let us dive into action! We will first develop our client as a normal java class without using Spring.

Standard Client

Listing 5. StandardUserServiceClient


package com.springapp;

import com.springapp.dao.UserDao;
import com.springapp.dao.UserDaoImpl;
import com.springapp.service.UserServiceImpl;
import java.util.Iterator;

/**
 *
 * @author James
 */
public class StandardUserServiceClient
{

    private UserServiceImpl userService;

    public StandardUserServiceClient()
    {
        userService = new UserServiceImpl();
        UserDao userDao = new UserDaoImpl();
        userService.setUserDao(userDao);
    }

    private void fetchUsers()
    {
        Iterator users = userService.getUsers();
        while (users.hasNext())
        {
            System.out.println(users.next());
        }
    }

    public static void main(String[] args)
    {
        StandardUserServiceClient client = new StandardUserServiceClient();
        client.fetchUsers();
    }
}

Hmm, there you can see our client code is “coupled” tightly with the service and dao implementations. That’s where Spring comes to our rescue. Spring will dynamically “inject” the implemenations so our application will remain “loosely” coupled.

Spring Client

But how will Spring know about our implementations? We need to inform Spring a little about our application and define the “hotspots” where it can dynamically “inject” the dependencies or implementations. Spring expects these details in a configuration file and let us quickly write that. Create a package called “resources” and create a xml file called “applicationContext.xm” inside it.

Listing 6. applicationContext.xml

In the “applicationContext.xml” file we defiend two beans named “userDao” and “userService”. We also specified their implementations using the “class” attribute. Also notice that we are setting the property “userDao” in the “UserServiceImpl” class with “UserDaoImpl” by referencing it’s name “userDao”. Pretty straighforward!

Now it’s time to churn out our Spring client.

Listing 7. SpringUserServiceClient


package com.springapp;

import com.springapp.service.UserService;
import java.util.Iterator;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 *
 * @author James
 */
public class SpringUserServiceClient
{
    private UserService userService;

    public SpringUserServiceClient()
    {
        //initialize the spring container
        ApplicationContext context = new ClassPathXmlApplicationContext("resources/applicationContext.xml");
        userService = (UserService) context.getBean("userService");
    }

    private void fetchUsers()
    {
        Iterator users = userService.getUsers();
        while(users.hasNext())
        {
            System.out.println(users.next());
        }
    }

    public static void main(String[] args)
    {
        SpringUserServiceClient client = new SpringUserServiceClient();
        client.fetchUsers();
    }
}

A couple of details about this class:

The ApplicationContext interface helps us to plug into the Spring container and lookup the classes we need by using the name we defined in the xml file.
There are many implementataions of ApplicationContext available in Spring. One of the most widely used implementation is “ClassPathXmlApplicationContext”. It is used to load Spring configuration files found in classpath.

As seen from Listing 7, Spring helps us to program to interfaces and develop loosely coupled applications. As a result, applications become more testable as there are no external dependencies like application server. It is also very easy to switch the implementations effortlessly. For example, in our sample application you can easily write a UserDaoMockImpl and use it in your test cases effortlessly.

Project Structure

Here is the complete application looks like:

Developing A Simple Pluggable Java Application

James — Sun, 20 Sep 2009 15:23:12 +0000

Most of the applications we use on daily basis are pluggable. Popular applications like Firefox, Eclipse, NetBeans, JEdit, WordPress, Hudson are all pluggable. In fact, pluggability has played a major part in the success of most of these applications. Why not make the Java applications we develop pluggable as well? Yes, we get pluggability out of the box, if our applications are based on a rich client platform like NetBeans or Eclipse. But for some reasons if you decide not to use those platforms, it doesn’t mean that they should not be pluggable. In this article, we will learn how to write a simple pluggable application that will load it’s plugins dynamically.

The API
First, let us define a plugin interface that should be implemented by all the plugins of our application. We are going to keep it very simple. Create a project called “plugin-api” in your favorite IDE and create the interface “ApplicationPlugin”.


package com.pluggableapp.plugins.api;

public interface ApplicationPlugin
{
    String getName();
    void init();
}

The Plugins

Writing the plugins now is very easy. Our plugins need to implement the plugin interface and follow a simple convention to make it easy for our applications to find them later. Create a project called “plugin-a” and develop our first plugin.


package com.pluggableapp.plugins;

import com.pluggableapp.plugins.api.ApplicationPlugin;
import java.util.logging.Logger;

public class PluginA implements ApplicationPlugin
{
    private static Logger logger = Logger.getLogger(PluginA.class.getName());

    public String getName()
    {
        return "Plugin A";
    }

    public void init()
    {
        logger.info(getName() + " initialized!");
    }
}

Now create a directory called “META-INF/services” inside the source directory and create a file with the name “com.pluggableapp.plugins.api.ApplicationPlugin” (This is the fully qualified name of the plugin interface). The file should contain the name of the actual plugin inside it. In our case, the text is “com.pluggableapp.plugins.PluginA”.

Repeat these steps to create PluginB.

The Application

It’s time to create the application that will consume the plugins we created. First let us create a class to add the plugin jars to the classpath dynamically.


package com.pluggableapp;

import java.io.File;
import java.io.IOException;
import java.lang.reflect.Method;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.logging.Logger;

public class ClasspathUtils
{

 private static Logger logger = Logger.getLogger(ClasspathUtils.class.getName());
 // Parameters
 private static final Class[] parameters = new Class[]
 {
     URL.class
 };

 /**
 * Adds the jars in the given directory to classpath
 * @param directory
 * @throws IOException
 */
 public static void addDirToClasspath(File directory) throws IOException
 {
     if (directory.exists())
     {
         File[] files = directory.listFiles();
         for (int i = 0; i < files.length; i++)
         {
             File file = files[i];
             addURL(file.toURI().toURL());
         }
     }
     else
     {
         logger.warning("The directory \"" + directory + "\" does not exist!");
     }
}

 /**
 * Add URL to CLASSPATH
 * @param u URL
 * @throws IOException IOException
 */
 public static void addURL(URL u) throws IOException
 {
     URLClassLoader sysLoader = (URLClassLoader) ClassLoader.getSystemClassLoader();
     URL urls[] = sysLoader.getURLs();
     for (int i = 0; i < urls.length; i++)
     {
         if (urls[i].toString().equalsIgnoreCase(u.toString()))
         {
             logger.info("URL " + u + " is already in the CLASSPATH");
             return;
         }
     }
     Class sysclass = URLClassLoader.class;
     try
     {
         Method method = sysclass.getDeclaredMethod("addURL", parameters);
         method.setAccessible(true);
         method.invoke(sysLoader, new Object[]
         {
             u
         });
     } catch (Throwable t)
     {
         t.printStackTrace();
         throw new IOException("Error, could not add URL to system classloader");
     }
  }
}

Now create an interface called “PluginService” to define the methods needed to load and initialize the plugins.


package com.pluggableapp;

import com.pluggableapp.plugins.api.ApplicationPlugin;
import java.util.Iterator;

public interface PluginService
{
    Iterator getPlugins();
    void initPlugins();
}

As of version 1.6, the Java runtime ships with a class called “ServiceLoader” to easily find and load plugins. Let us now write a implementation called “StandardPluginService” and make use of the facilities built into the java runtime.


package com.pluggableapp;

import com.pluggableapp.PluginService;
import com.pluggableapp.plugins.api.ApplicationPlugin;
import java.util.Iterator;
import java.util.ServiceLoader;
import java.util.logging.Logger;

public class StandardPluginService implements PluginService
{
    private static StandardPluginService pluginService;
    private ServiceLoader serviceLoader;
    private Logger logger = Logger.getLogger(getClass().getName());

    private StandardPluginService()
    {
        //load all the classes in the classpath that have implemented the interface
        serviceLoader = ServiceLoader.load(ApplicationPlugin.class);
    }

    public static StandardPluginService getInstance()
    {
        if(pluginService == null)
        {
            pluginService = new StandardPluginService();
        }
        return pluginService;
    }

    public Iterator getPlugins()
    {
        return serviceLoader.iterator();
    }

    public void initPlugins()
    {
        Iterator iterator = getPlugins();
        if(!iterator.hasNext())
        {
            logger.info("No plugins were found!");
        }
        while(iterator.hasNext())
        {
            ApplicationPlugin plugin = iterator.next();
            logger.info("Initializing the plugin " + plugin.getName());
            plugin.init();
        }
    }
}

Feel free to write your own implementation if needed. For example you can easily write an implementation based on the NetBeans API.

Write a factory class named “PluginServiceFactory” to create “PluginService” objects.


package com.pluggableapp;

import com.pluggableapp.*;
import com.pluggableapp.StandardPluginService;
import com.pluggableapp.PluginService;
import java.io.File;
import java.io.IOException;
import java.util.logging.Level;
import java.util.logging.Logger;

public class PluginServiceFactory
{
    public static PluginService createPluginService()
    {
        addPluginJarsToClasspath();
        return StandardPluginService.getInstance();
    }

    private static void addPluginJarsToClasspath()
    {
        try
        {
            //add the plugin directory to classpath
            ClasspathUtils.addDirToClasspath(new File("plugins"));
        } catch (IOException ex)
        {
            Logger.getLogger(PluginServiceFactory.class.getName()).log(
                Level.SEVERE, null, ex);
        }
    }
}

That’s it. All we need to do now is to write a class that will invoke the “PluginServiceFactory”.


package com.pluggableapp;

import com.pluggableapp.plugins.api.ApplicationPlugin;
import java.util.Iterator;
import java.util.logging.Logger;

public class Main
{

    private static Logger logger = Logger.getLogger(Main.class.getName());

    /**
    * @param args the command line arguments
    */
    public static void main(String[] args)
    {
        loadPlugins();
    }

    private static void loadPlugins()
    {
        PluginService pluginService = PluginServiceFactory.createPluginService();
        pluginService.initPlugins();
    }
}

Before we build and see the application in action, create a directory called “plugins” and put all plugin jars there.

And this is what you might see when you run our pluggable application.

Now feel free to create as many plugins you want to write and just drop them in the “plugins” directory and restart the “pluggable” application to see your “home grown” plugins in action!

Resources

Creating Extensible Applications With the Java Platform – John O’Conner

Developing a Java Plugin Framework

How to Create a Pluggable Photo Album in Java – Geertjan

Five different uses of Java Applets

James — Sat, 22 Aug 2009 09:54:42 +0000

In a world where everyone is using technologies like Flash, Silverlight etc to present rich content, are Java Applets still used? Are they still relevant? The answer is – “Yes”. Apart from being used primarily for playing online games, Java Applets are still used in many different ways. Here I would like to highlight a few applications that put Applets to good use.

1. Online Office Suite
ThinkFree is a very popular and professional online office suite based on Java Applet and Ajax.

2. Virtualization
JPC or Java PC Emulator is a pure java based virtualization software that can be used to boot your virtual computers right inside the browser. Yes they run as “Java Applets” inside the browser.

3. Remote Desktop Viewer
Products like TightVNC and UltraVNC provide a java applet based client to view remote desktops.

4. (Web) Operating System
iCloud, is an web operating sytem that makes use of XML and Java Applet Technology (atleast for Firefox).

5. File Upload

Facebook uses a beautifully designed Java Applet to upload photos to facebook photo albums.
net2ftp is a web based ftp client that makes use of tiny Java Applet to “drag and drop” files from local computer to the browser and upload them to the remote ftp server.

If you have come across any website that make use of Java Applets, please share your thoughts in the comments.

Hudson CI Server – A quick start guide

James — Fri, 24 Jul 2009 14:53:26 +0000

Introduction

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day.
- Martin Fowler

Hudson is a popular open-source continuous integration server used by many organizations like Redhat JBoss. Though there are many well known and well established open-source projects like CruiseControl, Continnum and some commercial offerings like Bamboo, what makes Hudson special is it’s powerful yet easy to use web interface, it’s simplicity and it’s extensible architecture with many plugins.

Objective

The objective of this tutorial is to setup, configure and learn to use Hudson by building “Apache Commons IO“, a well known java project.

Requirements

Hudson
Subversion (or any other version control system like CVS, Mercurial, Git if you want to build your own project)
(Optional) Tomcat or Glassfish
Apache Ant (or Maven)

Installation and Starting Hudson

Installing Hudson is super easy. Just download the war file, open your terminal/command-prompt and issue the command “java -jar hudson.war”. Now point your browser to http://localhost:8080. That was easy, right?

Hudson has an embedded servlet container called “Winstone” which works much like a standard servlet container like Tomcat by serving your JSP pages and servlets.

If you want Hudson to start on a different port, say 8180, issue the following command,
java -jar hudson.war –httpPort=8180

Ofcourse you can deploy Hudson to Tomcat, Glassfish or any other supported servlet containers. The following guides can be useful in that case:

More container specific guides can be found from this hudson wiki.

Once you started Hudson or deployed it to a servlet container, this is what you might see in your browser when you start Hudson for the first time.

Hudson Home Directory

All your Hudson jobs/settings are stored in the Hudson home directory. If you did not specify one, Hudson shall assume some defaults like ~/.hudson in Linux or your respective home directory in Windows. It’s ok to go ahead with the defaults while you test drive Hudson but once you are done, I strongly recommend you to define a Hudson home directory of your choice, preferrably on a separate partition or drive. This will ensure that all your Hudson configuration/jobs are intact in case of any system crash.

Say, suppose your home directory is “/hudson” (in Linux), this is how you will define the Hudson home directory,

If you are using the embedded servlet container, start it by specifying the java system property “HUDSON_HOME”,
java -DHUDSON_HOME=/hudson -jar hudson.war

If you are using Tomcat, follow the explanations in this wiki. However, if you run Tomcat as a windows service, you need to do some tweaking to let Tomcat set this property. In that case, you will be better off if you start Tomcat using it’s batch file and set the property right there. (Or if you managed to run Tomcat as a Windows Service and still able to define the Hudson home correctly, why don’t you share your views with us?)

If you are using Glassfish, go to admin console and add the JVM option -DHUDSON_HOME=/hudson. More detailed explanations can be found on this wiki.

Just remember that the idea is to define a system property “HUDSON_HOME” through any of the possible ways.

This is how the Hudson home directory shall look like.

Manage Hudson

Hudson provides an easy to use web interface to manage the configurations needed to administer a continuous integration server. Let us do some basic configurations to get Hudson ready.

Start Hudson and click the “Manage Hudson” link located on the left.

Now click “Configure System”. Hudson will display a page where you can configure things like access control, JDK, Ant, Email Settings etc.

Access Control

We will enable security to secure our Hudson setup. Otherwise anybody can go and meddle with your Hudson jobs. If you don’t want that to happen, check the “Enable Security” checkbox.

Once security is enabled, we need to tell Hudson the type of “Access Control” we want to use. Let us choose the Security Realm as “Hudson’s own user database” and leave the option “Enable users to signup” as checked. (If you do not check the “sign up” option here, Hudson is definitely going to whack you later!. ) Under the “Authorization” section, choose “Matrix-based Security”.

Now add an user called “administrator” and give the necessary privileges. ENSURE THAT YOU GIVE “ADMINISTER” PRIVILEGES TO THIS USER or else, you may not able to access the administrative console once security and access control are enabled. (Again, if you miss it, Hudson is gonna whack you!)

Hudson will display an error symbol near the user we just added. That’s because the user does not exist in the system. Do not bother, we will create the user a little later. Now go ahead and add users who might be accessing Hudson. Give appropriate access controls to the users and do not give full access to everyone. That will eventually create a system that is difficult to manage.

Configure JDK

Done with security? Now we need to configure the JDK which Hudson shall use to build the jobs. Find out the section “JDK” in the same page. Click the “Add JDK” button and then enter the details of your JDK.

Configure Ant

We need to tell Hudson where Ant is located. Find out the section called “Ant”, click “Add Ant” and enter the respective details.

(Follow the same procedure, if you want to configure Maven.)

That’s it! Hudson is now almost ready for prime time. Feel free to configure the Email Settings as well with the appropriate values. When you are done, press the “Save” button to save all the changes you have made.

Once you press the “Save” button, Hudson will redirect you to a login page.

Manage Users

Click the “Signup” link at the top right corner of Hudson and register a new user called “administrator” (or whatever name you gave in the “Access Control” section).

Hudson will automatically login the user provided the user was already configured in the “Access Control” section. Once a new user (administrator) is registered in the system, Hudson will provide an option called “Manage Users” in the “Manage Hudson” page.

You can now create other users from this page.

You will be using this page to manage all your Hudson users. Looks like we have covered quite a lot of information. It’s time now to create some jobs and see Hudson in action.

Creating Job

That’s the core feature of Hudson. Hudson jobs can fetch the source code from a repository, execute your build scripts, run your tests, prepare javadoc, notify you in case of any failure, archive the build artifacts and much more. That’s where you can really see the power of Hudson. Enough talking, let us explore these Hudson features now by creating a job.

The Hudson job which we are going to create now is going to be very simple and is capable of doing the following:

Checkout the source code of apache commons-io project using subversion
Run the build script (build.xml in case of Ant, pom.xml for Maven)
Archive the build output

Create a job by clicking the link “New Job” on the left. Give a name for the job, select the option “Build a free-style software project” and then press “OK”.

Configure Job

Hudson will create a new empty job for us which we need to configure.

Let us configure the repository for this job first. Go to the section “Source Code Management”, choose the option “Subversion” and enter the repository url as “http://svn.apache.org/repos/asf/commons/proper/io/trunk“. Enter the “Local module directory” as “.”

Look for the section called “Build”. Click the button “Add build step” and select “Invoke Ant”. Leave the rest to default. (Maven users, choose the appropriate action)

Go to the section “Post-build Actions”. Select the checkbox “Archive the artifacts”. The apache commons-io build script shall create the jar in the directory named “target”. So enter the value “target/*.jar” in the text field titled “Files to archive”. Though this is not mandatory to build a job, I recommend you to do this as this will help the users of your continuous integration server to download the build outputs quickly.

NOTE: Since we are building the apache-commons-io project we are entering the value “target/*.jar”. If for example, your build output directory is “dist”, then you should enter here as “dist/*.jar”.

Press the “Save” button at the bottom. Our job is ready and just click link “Build Now” at the left to start building the job.

Once the build is initiated, you can relax and watch the progress in the “Build History”.

If you are restless and want to see exactly what is going on, just click the link (corresponding to the build number) in the “Build History”.

Now click the link “Console Output”.

Hudson will display you the console view where you can do all your research.

Now that the build is successful, you might want to have a look at the jar built by this job. You can find that under “Last Successful Artifacts”.

You can also have a sneak preview about the builds from your Hudson home page.

If in case some of your builds failed, Hudson will report that as well neatly along with displaying the build stability.

That’s it for now. But you can do a lot more like configuring Hudson to build this job every few minutes or just poll the repository once in a while and trigger the build whenever someone commits to the repository. Explore them under the job’s configuration page and enjoy. And did I mention that Hudson has a lot of good plugins already? Maybe I will try to cover those advanced concepts in my next post.

If you are using NetBeans as your IDE, then you have a got a lot of Hudson features integrated right into the NetBeans IDE. Check that out in my post NetBeans 6.7 – A quick glance.

Are you using Hudson? Are you planning to use Hudson? Why not leave a comment below and share your thoughts?

NetBeans 6.7 – A quick glance

James — Tue, 07 Jul 2009 15:30:58 +0000

NetBeans 5.0 – Simplified Swing development
NetBeans 5.5 – Simplified Java EE development
NetBeans 6.0 – Made the NetBeans editor and other core infrastructure on par with competitors
NetBeans 6.5 – Looked beyond Java development by supporting languages like PHP
NetBeans 7.0 6.7 – Tries to make collaborative team development seamless.

I was quick to download the “All Java” pack of NetBeans IDE for linux. Installation, as usual was pretty smooth on my Ubuntu 9.04. The installation didn’t give me much surprises and it was very much similar to version 6.5. I customized the installer to install Glassfish v2.1 and Tomcat 6.0.18 for me.

Splash Screen
The splash screen has changed a bit and the startup was quick. But I wouldn’t comment about the startup speed at this point of time since I haven’t created/opened any projects in the IDE.

Intuitive Start Page
The start page has got the much needed face lift and is very attractive. The big and clean text reminded me about Eclipse which has got a really good start page. With this new start page, installing plugins is just one click away.

The start page also offers an intuitive way to activate/de-activate IDE features. Say suppose you don’t want certain IDE features, for example, Mobile development, it’s very easy to turn it off right from your start page. Good work!

Hudson Integration
That’s my favourite feature in this release of NetBeans. Hudson is a great continuous integration server which helps you to automate your build process. And if your team uses Hudson, then this NetBeans feature might be very useful to you. As per my understanding, currently NetBeans supports only Hudson continuous integration server. If you are using other CI servers like CruiseControl, no great news for you in this release of NetBeans.

Open the “Services” window in the IDE and look for “Hudson Builders”. There you can add your existing hudson urls.

With the hudson support, you can now manage the hudson jobs without opening a browser. You can even copy the build artifacts to your netbeans projects.

You can also watch the remote hudson build console at the comfort of your IDE.

Issue Tracker Integration
If you are doing any serious development, it’s most likely that you will be using some issue tracker. There are many popular issue trackers available like Bugzilla, Trac, Jira etc. NetBeans 6.7 provides out of the box support for Bugzilla but Jira support is available as well through a plugin.

I registered my mozilla issue tracker account in the IDE. Once an issue tracker is registered, you can find as well as add/modify issues.

Finding issues from a bugzilla based issue tracking system is just a click away.

Reporting new issues is not a tough job either.

I didn’t try the Jira integration yet. In future, I would love to see integration with more issue trackers like Trac.

Error Reporting
Another neat feature which I like in this release is the enhancements made to the exception reporter.
In previous versions of NetBeans, the issue log file shall be uploaded to the netbeans server and you will be displayed a message in the browser regarding the status of the issue. Now that’s integrated into the IDE as well.

You can view all the issues filed by you by clicking the button “Show my issues”.

Others

Other highlighed feature of NetBeans is “Project Kenai” integration. For those who are wondering what is this all about, “Project Kenai” is a place to host your open source projects much like sourceforge, google code, launchpad etc. But I couldn’t complete my testing on this NetBeans feature and as such I couldn’t write about this at this point of time. But to be frank, I’m not very excited about this feature. A sourceforge.net integration would have made me much happier but nevertheless it’s a great effort put forward by NetBeans team.

There are many other improvements in the areas of code completion, debugging, profiling, Maven support, Groovy support etc. You can get more details about that from the netbeans wiki.

Summary
Overall, NetBeans 6.7 builds on the strong platform of 6.x series and takes team development one step further. Hudson integration is really very good and I believe Bugzilla integration is also pretty good. But there are not many new features in this release that can make a Java developer happy. Whatsoever, it’s a great effort from the NetBeans team and we must appreciate them for this solid work. So what about you? Have you tried NetBeans 6.7? How do you feel about it?

New!

Learn more about Hudson from the blog post Hudson CI Server – A step by step guide – Part I.

Getting NetBeans ready for work on Ubuntu 8.10

James — Wed, 04 Feb 2009 08:39:16 +0000

Now that you have upgraded from Windows to Ubuntu (like me ), let’s see how to setup NetBeans quickly on your new Ubuntu machine without wasting much time.

Step 1: Install JDK

Install jdk on your machine using the super easy install option in Ubuntu. Open the terminal and type:

sudo apt-get install sun-java6-jdk

This will install the latest jdk available in the Ubuntu repository. This is cool because, you need not worry about updating your jdk whenever a new release is available. Your system’s “Update Manager” will take care of the rest.

Once the jdk is downloaded, you will be prompted to agree a license agreement in the terminal. Press “TAB” key to select the “Ok” option and then press “Enter”.

Next you will be shown another prompt, use your “arrow” keys to select “Yes” option and press “Enter” to start the install process.

Step 2: Install NetBeans

Verify whether jdk is installed on your machine by typing “java -version” in the terminal. If everything is ok, go and get yourself a copy of netbeans installer.

Once the netbeans installer is downloaded, right click the downloaded file (which should have “.sh” extension), click “Properties”, go to the “Permissions” tab and check the “Allow executing file as program” checkbox.

Now double click the file and click “Run” to start the installation process.

Step 3: Start NetBeans with Nimbus Look and Feel

Let’s face it. The default look and feel (GTK) of NetBeans on Ubuntu (and that of Ubuntu too) sucks. You probably don’t want your friends to ridicule your IDE and say “Is this NetBeans 1.0?”. You don’t want that, right?

But fortunately, there is a saviour in the form of “Nimbus” which is available from JDK 6 Update 10 onwards. And instructing NetBeans to start with “Nimbus” look and feel is very easy. Just right click your “NetBeans” icon on your desktop and click “Properties”. In the “Command” text field add the word ” –laf Nimbus”.

In my case, it looks like:

/bin/sh “/home/james/netbeans-6.5/bin/netbeans” –laf Nimbus

Now restart NetBeans to see your IDE skinned in Nimbus.

Tip:
If you want NetBeans to look like other apps on your system, skin your Ubuntu with Nimbus theme too.

Step 4: Configure your video driver to ensure that NetBeans displays large files properly

In a perfect world, you don’t need this step but unfortunately you might need to configure your video driver properly to ensure that NetBeans displays large files properly. Otherwise, your IDE editor might display large files like this when you scroll your mouse:

Relax, this is not a bug in NetBeans but rather it’s just a little misconfiguration by Ubuntu. Fortunately, there is a solution to this issue and follow this netbeans wiki page to solve this.

Step 5: Choose the right font for your editor

Some of you might not like the default font used by the NetBeans editor on Ubuntu. For example, I like the crispy “Bitstream Vera Sans Mono” font with font size “13″. But if you are satisfied with the default editor font, it’s fine.

Step 6: Install path-tools plugin to integrate NetBeans with your filesystem browser

I strongly recommend you to use the excellent “path-tools” plugin which help you to integrate your NetBeans IDE with the nautilus file manager in Ubuntu. With this plugin, you can easily navigate to your netbeans projects located in your filesystem. Go grab it from the plugin portal.

And don’t forget to install your favourite version control system like subversion, mercurial, git etc to enjoy the benefits offered by your IDE.

That’s it for now. It will be great to see your suggestions, comments and tips you employ on your Ubuntu machine. Enjoy..!