SolitaryGeek » James

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.

Book Review: NetBeans Platform 6.9 Developers Guide

James — Fri, 10 Sep 2010 09:26:02 +0000

NetBeans has been my IDE of choice for the past few years and to my pleasure, I recently received a copy of NetBeans Platform 6.9 Developers Guide from Packt. So, I thought of coming out with a review of this book.

A bit about the NetBeans Platform

“The NetBeans Platform is a generic framework for Swing applications. It provides the “plumbing” that, before, every developer had to write themselves—saving state, connecting actions to menu items, toolbar items and keyboard shortcuts; window management, and so on. The NetBeans Platform provides all of these out of the box. You don’t need to manually code these or other basic features, yourself, anymore.” – from the NetBeans Platform site.

And from Boeing to governments, lot of applications are being built on top of the NetBeans platform.

Do I need a technical book to learn about the NetBeans Platform?

Though the NetBeans Platform has a rich set of online documentation, readers’ taste can differ and books are great at delivering the right content to the right audience.

Some might prefer a book to get started with a particular topic, some might want to read a book with in-depth technical content.

And it’s great to see more and more books are targeted at the NetBeans Platform.

Who can benefit from this book?

Are you planning to develop any desktop application? Why not develop your application on top of the NetBeans Platform, which gives you a lot of must have features in every desktop application? Why re-invent the wheel?

Even if you have an existing desktop application, it’s a great idea to port it to NetBeans Platform. Just remember the “DRY” (Don’t repeat yourself) principle.

Do you use the NetBeans IDE to create web or mobile applications but miss your favourite feature in the IDE? Why not write some plugins yourself?

What ever may be your case, this book can give you a good start at NetBeans Platform.

What’s so special about this book?

As I started reading a couple of chapters, I got impressed with the way the content is delivered.

The book starts with the traditional “Hello World” module and takes the reader to the advanced topics in an elegant and seamless manner.
The author makes good use of screenshots which will help the beginners a lot.

Like many other popular titles, this book takes an application (in this case, a Task Manager) and attempts to build it through every chapter.
This undoubtedly will help the readers master the platform concepts quickly.

Right from the basic form components, the book covers virtually every aspect of the NetBeans Platform like the Window System, Data System, Branding etc.
There’s even an chapter to help you create installers for your application.

The most noticeable feature I found in this book is the friendly language and the clear explanation of topics having beginners in mind.
I haven’t finished reading all the chapters yet, but I hope to complete it shortly. My objective is to write a couple of plugins for the NetBeans IDE and I hope this book will help me achieve that pretty quickly.

You can get this book from Packt and Amazon.

Switched the hosting provider

James — Mon, 28 Jun 2010 03:45:15 +0000

Dear readers,
Thanks for your patience. I’ve successfully moved my blog from my old hosting provider.

Still something might be broken. I’m working them out one by one. Thanks for your support.

Changing the hosting provider

James — Fri, 25 Jun 2010 01:49:33 +0000

Dear readers,

Sorry for the down time. I’m in the process of changing to a different hosting provider. The blog should be up in a couple of days.

Windows 7 RC Expiration

James — Wed, 17 Feb 2010 02:01:59 +0000

I received a mail from Microsoft today morning about Windows 7 expiration. Here is the essence of the mail:

It’s time to upgrade from the Windows 7 Release Candidate

While most people who tested Windows 7 have now moved to the final version, some are still running the Release Candidate. If you haven’t moved yet, it’s time to replace the RC.

Starting on March 1, 2010 your PC will begin shutting down every two hours. Your work will not be saved during the shutdown.

The Windows 7 RC will fully expire on June 1, 2010. Your PC running the Windows 7 RC will continue shutting down every two hours and your files won’t be saved during shutdown. In addition, your wallpaper will change to a solid black background with a persistent message on your desktop. You’ll also get periodic notifications that Windows isn’t genuine. That means your PC may no longer be able to obtain optional updates or downloads requiring genuine Windows validation.

To avoid interruption, please reinstall a prior version of Windows or move to Windows 7. In either case, you’ll need to do a custom (clean) install to replace the RC. As with any clean installation, you’ll need to back up your data then reinstall your applications and restore the data. For more details about replacing the RC, see the Knowledge Base article KB 971767. For more information, visit the Window 7 Forum.

Thanks again for helping us test Windows 7.

The Windows 7 Team

This sounds very unprofessional and disappointing. Why shutdown the operating system every 2 hours? Why change the wall paper to “a solid black background with a persistent message on your desktop”?. Why display “periodic notifications that Windows isn’t genuine”?. Did we cheat Microsoft by running Windows 7 RC? Why not just expire gracefully with some friendly reminders.

What do you think about this?

You can get more information about Windows 7 RC expiration from Microsoft Knowledge Base.

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