A ContentProvider is a first-class Android component (like Activity, Service, etc). It is registered in the manifest file like any other high-level components. You can read about Android ContentProviders from Android’s website at:

• http://developer.android.com/reference/android/content/ContentProvider.html – API doc
• http://developer.android.com/guide/topics/providers/content-providers.html – Content Provider usage

The intent of this write up is to present a simple approach to create and work with your own ContentProvider. It is not meant to be an introduction to data storage in Android. If you have not used data storage in Android, visit the Android’s developer web site and look for data storage.

Descriptor Class

public class ContentDescriptor {
	public static final String AUTHORITY = "demo.contentprovider.restaurant";
	private static final Uri BASE_URI = Uri.parse("content://" + AUTHORITY);
	public static final UriMatcher URI_MATCHER = buildUriMatcher();

	private ContentDescriptor(){};

	private static  UriMatcher buildUriMatcher() {
        final UriMatcher matcher = new UriMatcher(UriMatcher.NO_MATCH);
        final String authority = AUTHORITY;

        matcher.addURI(authority, Restaurant.PATH, Restaurant.PATH_TOKEN);
		matcher.addURI(authority, Restaurant.PATH_FOR_ID, Restaurant.PATH_FOR_ID_TOKEN);

        return matcher;
	}

	public static class Restaurant {
		public static final String NAME = "restaurant";

		public static final String PATH = "restaurants";
		public static final int PATH_TOKEN = 100;
		public static final String PATH_FOR_ID = "restaurants/*";
		public static final int PATH_FOR_ID_TOKEN = 200;

		public static final Uri CONTENT_URI = BASE_URI.buildUpon().appendPath(PATH).build();

		public static final String CONTENT_TYPE_DIR = "vnd.android.cursor.dir/vnd.favrestaurant.app";
		public static final String CONTENT_ITEM_TYPE = "vnd.android.cursor.item/vnd.favrestaurant.app";

		public static class Cols {
			public static final String ID = BaseColumns._ID; // convention
			public static final String NAME = "restaurant_name";
			public static final String ADDRESS  = "restaurant_addr";
			public static final String CITY = "restaurant_city";
			public static final String STATE = "restaurant_state";
			public static final String ZIP = "restaurant_zip";
		}

	}
}

public class RestaurantDatabase extends SQLiteOpenHelper {
	private static final String DATABASE_NAME = "fav_restaurnt.db";
	private static final int DATABASE_VERSION = 2;

	public RestaurantDatabase(Context ctx){
		super(ctx, DATABASE_NAME, null, DATABASE_VERSION);
	}

	@Override
	public void onCreate(SQLiteDatabase db) {
		db.execSQL("CREATE TABLE " + ContentDescriptor.Restaurant.NAME+ " ( " +
				ContentDescriptor.Restaurant.Cols.ID + " INTEGER PRIMARY KEY AUTOINCREMENT, " +
				ContentDescriptor.Restaurant.Cols.NAME + " TEXT NOT NULL, " +
				ContentDescriptor.Restaurant.Cols.ADDRESS 	+ " TEXT , " +
				ContentDescriptor.Restaurant.Cols.CITY + " TEXT, " +
				ContentDescriptor.Restaurant.Cols.STATE + " TEXT, " +
				ContentDescriptor.Restaurant.Cols.ZIP + " TEXT, " +
				"UNIQUE (" +
					ContentDescriptor.Restaurant.Cols.ID +
				") ON CONFLICT REPLACE)"
			);
	}

	@Override
	public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        if(oldVersion < newVersion){
        	db.execSQL("DROP TABLE IF EXISTS " + ContentDescriptor.Restaurant.NAME);
        	onCreate(db);
        }
	}

}

The ContentProvider Class

public class RestaurantContentProvider extends ContentProvider {
	private RestaurantDatabase restaurantDb;

	@Override
	public boolean onCreate() {
		Context ctx = getContext();
		restaurantDb = new RestaurantDatabase(ctx);
		return true;
	}

	@Override
	public String getType(Uri uri) {
		final int match = ContentDescriptor.URI_MATCHER.match(uri);
		switch(match){
		case ContentDescriptor.Restaurant.PATH_TOKEN:
			return ContentDescriptor.Restaurant.CONTENT_TYPE_DIR;
		case ContentDescriptor.Restaurant.PATH_FOR_ID_TOKEN:
			return ContentDescriptor.Restaurant.CONTENT_ITEM_TYPE;
        default:
            throw new UnsupportedOperationException ("URI " + uri + " is not supported.");
		}
	}

	@Override
	public Uri insert(Uri uri, ContentValues values) {
		SQLiteDatabase db = restaurantDb.getWritableDatabase();
		int token = ContentDescriptor.URI_MATCHER.match(uri);
		switch(token){
			case ContentDescriptor.Restaurant.PATH_TOKEN:{
				long id = db.insert(ContentDescriptor.Restaurant.NAME, null, values);
				getContext().getContentResolver().notifyChange(uri, null);
				return ContentDescriptor.Restaurant.CONTENT_URI.buildUpon().appendPath(String.valueOf(id)).build();
			}
            default: {
                throw new UnsupportedOperationException("URI: " + uri + " not supported.");
            }
		}
	}

	@Override
	public Cursor query(Uri uri, String[] projection, String selection,
			String[] selectionArgs, String sortOrder) {
		SQLiteDatabase db = restaurantDb.getReadableDatabase();
		final int match = ContentDescriptor.URI_MATCHER.match(uri);
		switch(match){
			// retrieve restaurant list
			case ContentDescriptor.Restaurant.PATH_TOKEN:{
				SQLiteQueryBuilder builder = new SQLiteQueryBuilder();
				builder.setTables(ContentDescriptor.Restaurant.NAME);
				return builder.query(db, null, null, null, null, null, null);
			}
			default: return null;
		}
	}

	@Override
	public int update(Uri uri, ContentValues values, String selection,
			String[] selectionArgs) {
		return 0;
	}

	@Override
	public int delete(Uri uri, String selection, String[] selectionArgs) {
		return 0;
	}
}

Using the ContentProvider

public class FavRestaurantActivity extends Activity {
	TextView txtName;
	TextView txtAddr;
	TextView txtState;
	TextView txtCity;
	TextView txtZip;

    ContentResolver contentResolver;
    Cursor cur;
    SimpleCursorAdapter adapter;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        ...
        contentResolver = this.getContentResolver();
    }

    @Override
    public void onStop() {
    	super.onStop();
    	if(cur != null) cur.close();
    }

    private void loadContent() {
        cur = this.getContentResolver().query(ContentDescriptor.Restaurant.CONTENT_URI, null, null, null, null);
    	...
    }

    private void saveContent(){
    	ContentValues val = new ContentValues();
    	val.put(ContentDescriptor.Restaurant.Cols.NAME, (this.txtName.getText() != null) ? this.txtName.getText().toString() : null);
    	val.put(ContentDescriptor.Restaurant.Cols.ADDRESS, (this.txtAddr.getText() != null) ? this.txtAddr.getText().toString() : null);
    	val.put(ContentDescriptor.Restaurant.Cols.CITY, (this.txtCity.getText() != null) ? this.txtCity.getText().toString() : null);
    	val.put(ContentDescriptor.Restaurant.Cols.STATE, (this.txtState.getText() != null) ? this.txtState.getText().toString() : null);
    	val.put(ContentDescriptor.Restaurant.Cols.ZIP, (this.txtZip.getText() != null) ? this.txtZip.getText().toString() : null);
    	contentResolver.insert(ContentDescriptor.Restaurant.CONTENT_URI, val);
    	loadContent();
    }
}

There is still a great number of Java developers out there who are not doing web apps. They use the JDK’s Java launcher directly to bootstrap their apps using public static void main() (abbreviated thereafter as PSVM). And if you are one of those developers, you understand the implications of having a large classpath. It is not uncommon to see shell command with no less than a dozen jars listed on the classpath.

Of course over the years many options have been provided to help with this issue. One of the most recent is from Java 6 where you can reduce the length of the command to launch your Java application by specifying wildcards values in the classpath as shown below:

$ java -cp path1/*.jar:path2:/*:path3/*.jar package.name.ClassName

This write up proposes an alternative approach where your code loads your application’s classes programatically. This pattern, named Loader/Launcher, separates the loading of your application’s classes from the booting of your application logic. The idea is to provide your own loader class that will load your classpath then delegates further bootstrapping responsibilities to a launcher class. One benefit of this approach is that your command to launch your application can be reduced to something like this (no matter the size of your class dependency graph):

$ java -jar package.name.ClassName

The Loader/Launcher Pattern

The way that the Loader/Launcher pattern works is to de-entangle class-loading concerns from application execution concerns. The loading of classes is handled by a Main class with a PSVM method. The native Java command-line launcher loads the Main class. The execution of the application is delegated to a launcher class that implements the Launcher interface. The Launcher is instantiated and invoked by the Main class.

Loader/Launcher Sequence

To implement this pattern, you will need the following high-level components:

• The Launcher interface that will be used as a starting point for your app.
• The Main class where a PSVM method is defined.
• A Launcher implementation to execute the application.

The Launcher Interface

Implementation of this interface is intended to be the starting point of your application’s bootup process. Instead of starting your application directly in the PSVM method, as is done traditionally, you would relocate the logic for your application’s boot up sequence in a class that implements this interface. When the PSVM method is invoked by the native Java launcher, it would delegate the boot sequence of your application to your Launcher instance (see interface below Listing-1).

public interface Launcher {
	public int launch(Object ... params);
}

Listing-1

This is a simple interface with a single method, launch(). The method takes an array of objects that can be used to pass in arguments to launcher. The method’s signature makes easy to maintain the semantic of PSVM when using the Launcher.

The Main Class

The Main class is designed to be the starting point for the native Java launcher by exposing a PSVM method. The role of this class, in the Loader/Launcher Pattern, is summed up below:
It creates and loads the application’s classpath. Internally, it instantiates a ClassLoader that is used to load the application’s classpath from a specified location.
Once the classpath is in place, it creates an instance of Launcher, from the classpath, to boot up the application by calling launch().

Listing-2 shows the content of a Main class.

public class Main {
	private static String CLASSPATH_DIR = "lib";
	private static String LIB_EXT = ".jar";
	private static String LAUNCHER_CLASS = "demo.launcher.AppLauncher";

	private static ClassLoader cl;
	static{
		try {
			cl = getClassLoaderFromPath(
				new File(CLASSPATH_DIR),
				Thread.currentThread().getContextClassLoader()
			);
			Thread.currentThread().setContextClassLoader(cl);
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

	// Returns a ClassLoader that for the provided path.
	private static ClassLoader getClassLoaderFromPath(File path, ClassLoader parent) throws Exception {
		// get jar files from jarPath
		File[] jarFiles = path.listFiles(new FileFilter() {
			public boolean accept(File file) {
				return file.getName().endsWith(Main.LIB_EXT);
			}
		});
		URL[] classpath = new URL[jarFiles.length];
		for (int j = 0; j < jarFiles.length; j++) {
			classpath[j] = jarFiles[j].toURI().toURL();
		}
		return new URLClassLoader(classpath, parent);
	}

	public static void main(String[] args) throws Exception{
		Launcher launcher = Launcher.class.cast(
			Class.forName(LAUNCHER_CLASS, true, cl).newInstance()
		);
		launcher.launch(new Object[]{"this string is capitalized"});
	}
}

Listing-2

The first thing to notice is the static declarations at the start of the listing. The first three declarations setups the “lib” directory as the location for the classpath, provides “.jar” as the file extension, and specifies demo.launcher.AppLauncher as the name of the Launcher class to load from the classpath. The static code block uses method getClassLoaderFromPath() to initialize a URLClassLoader instance (that points to the lib directory) that will serve as the class loader for the rest of the application.

When the public static void main() method in the Main class is invoked (by the Java launcher), it searches and loads an instance of class demo.launcher.AppLauncher which implements Launcher. Then, the code calls Launcher.launch() to delegate the execution of the rest of the application by passing in a String parameter.

The Launcher Class

The Launcher class is responsible for starting up the application-specific logic. Implementation of the launch() method maintains the same signature as the the PSVM method from the Main class to maintain the familiar semantic. Parameters are passed in as arrays of objects and the method is expected to return an integer. A return value of 0 means everything is OK while anything else means something up to the discretion of the implementor. Listing-3 shows a simple implementation of the Launcher class.

public class AppLauncher implements Launcher {
	public int launch(Object ... args) {
		String result = org.apache.commons.lang3.text.WordUtils.capitalize((String)args[0]);
		System.out.println (result);
		return 0;
	}
}

Listing-3

How It Works

This implementation uses Apache Commons-Lang to capitalize the value of an argument that was passed in. While this is a simple example, it shows exactly how the pattern would work.  When the application is invoked from the command-line using

$ java -jar demo.launcher.Main

The Main class resolves the classpath by loading jars from the jar directory.  The classpath directory contains all jars that satisfies the dependency graph of the application.  In this example the application depends on the Apache-Commons Lang jar.  When Main instantiates its ClassLoader instance, the jar will be added on the classpath and thus be available for use.

An Example

You can download example code that shows how this works from the location below:
An example – https://github.com/vladimirvivien/workbench/tree/master/CustomLauncher

The example comes in three separate projects:

• Launcher-Api – contains the definition of the Launcher interface.
• Launcher-Impl – contains an implementation of the Launcher interface.
• Laucnher-Main – contains the Main class that is used as the starting point of the application.

Conclusion

The Loader/Launcher Pattern is an attempt to decouple two distinct activities that occur when a Java application is started: that of class loading and and application start up. The pattern uses a Main class as the entry point from the Java native launcher and is used to  load the application’s classpath from a given location.  The act of activating the application is then relegated to a Launcher class.  The launcher is responsible for actually starting up the application-specific logic in the code.  Some of the benefit of adopting this pattern is, firstly, the tighter control over how classes are loaded.  You no longer have to rely on the native Java launcher to resolve your classpath.  Another benefit is the separation of concerns for the start up sequence of the app.  The pattern provides a location, the Launcher interface, where to define what should happen when the application itself (not loading of classpath) is starting.  Hope this was helpful.

Reference

https://github.com/vladimirvivien/workbench/tree/master/CustomLauncher - the example

http://code.google.com/p/clamshell-cli/ - tool that uses this pattern

The best tribute to Steve is to imitate some of his legacies. So, in your next project, make your creation better. If you are designing an API, add that extra function that makes your developers productive; if you are creating a web site , add that feature that will surprise and make your users smile; if you are creating a new product, plan to make it great, plan to make it usable, plan to make it awesome.

I can only hope that the people at Apple don’t fall prey to the temptation of only pleasing the Street but continue Steve’s long-term strategic vision of bringing quality and imaginative products out to the market. As Apple’s recent history attests to, people will gravitate toward quality and the Street will take notice.

Thank you Steve Jobs 

• http://developer.android.com/resources/tutorials/views/hello-listview.html - shows a simple example on how to use the ArrayAdapter when your data source (as you would guess) is the form of a array (Java type or XML array resource).
• http://developer.android.com/resources/tutorials/views/hello-gridview.html - shows how to create grid view along with an Adapter to provide data for the the view.

Create Your Own Adapters

In non-trivial Android development, chances are you have a complex data graph to maintain states.  Rather then trying to fit your data structure to work with the out-of-the-box adapters, it is relatively easy to just create your own.  As a measure of practice, you should create a custom Adapter implementation for your views (specially ListView instances).  Why?  Your own Adapter class will be more flexible and you will add just enough functionality needed and avoid carrying around bloated code.

A Simple Implementation

The following is derived from a simple implementation which prompted this writing.  I have a simple class Application which I want to bind to a ListView.  Since we are going to use an Adapter we will break down the components as follow: list_layout.xml, item_layout, a data transfer object, and the activity where everything is displayed.

Main Layout – list_layout.xml
This is used for the Activity layout.  It contains the ListView instance that will be bound to the adapter.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <ListView
        android:id="@+id/my_list"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:layout_weight="1"
        android:drawSelectorOnTop="false"
        android:textFilterEnabled="false"
        android:stackFromBottom="false"/>
</LinearLayout>

Row Layout – item_layout.xml
This layout is used by the Adapter instance to generate the view used for each item (row) in the ListView.  Use this layout to customize how you want each row in the bounded list view to appear.  In this example, we are going to have a simple TextView instance in each row.

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal"
    android:padding="12sp">

        <TextView android:id="@+id/data_item"
            android:textSize="18sp"
            android:textStyle="bold"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"/>

</LinearLayout>

Data Transfer Object
This object is part of the internal object graph that is used to maintain state.  It is used by the Adapter as the data source for information bound to the view.

public class MyData{
    private String item;
    public String getItem(){return name;}
    public void setItem(String n){name = n;}
}

The Activity (Abbreviated)
The following shows an abbreviated version of a definition for an Activity class that uses the defined ListView (see above).  Although it looks intimidating, this Activity class contains all the basics of a normal Activity class.  However, part of the definition an Adapter class used to bind data to the ListView (see class MyListAdapter).

public class MyListActivity extends Activity{
    ListView listView;
    List<MyData> dataSource;
    MyListAdapter adapter;

    ...

    @Override
    public void onCreate(Bundle savedInstanceState) {
        this.setContentView(R.layout.list_layout);
        listView = (ListView) findViewById(R.id.my_list);
        dataSource = new ArrayList<MyData>();
        adapter = new MyListAdapter(this, R.layout.item_layout, dataSource);
        listView.setAdapter(adapter);
        ...
	}

	// private Adapter for my list
	private static class MyListAdapter extends BaseAdapter {
	    private Activity parentActivity;
	    private int itemLayoutId;
	    private List<MyData> dataSource;
	    private LayoutInflater inflater;

		// constructor for adapter
    	    public MyListAdapter(Activity activity, int layoutId, List<MyData> ds){
    		parentActivity = activity;
    		itemLayoutId = layout;
    		dataSource = ds;
    		inflater = (LayoutInflater)context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    	    }

		@Override
		public View getView(int pos, View convertView, ViewGroup parentView){
			View view = null;
			if(convertView == null){
				view = inflater.inflate(itemLayoutId, parentView, false);
				TextView textView = (TextView)view.findViewById(R.id.data_item);
				String data = dataSource.get(pos).getItem();
				textView.setText(data);
			}else{
				view = convertView;
			}
			return view;
		}
	}
}

If you have implemented an Activity before, the beginning should look familiar.  In the onCreate() method, we bind the Activity to the main layout my_list.  Next we pull out the ListView instance from that layout and set its adapter to an instance of the custom adapter class defined by MyListAdapter.

The class MyListAdapter is simple.  It extends the BaseAdapter which is provided by the SDK as a starting point for custom adapters.  You must override public method getView() as shown above.  This method will be called by the View instance, bound to this adapter, to draw the portion of the View that displays the data at the specified position in the data set.  In the snippet, we use and Inflater to reconstruct the View represented by R.layout.item_layout.  Then bind the data to a TextView instance contained in the layout.  The entire inflated View instance is returned by getView() to be used by the parent view.

Beware!

While getView() provides the core logic for your adapter to expose your custom data.  I found that it’s also important to override the following methods shown below.  If not you will spend hours trying to figure out why your list is not displaying properly.

    private static class MyListAdapter extends BaseAdapter{
    ...
        @Override
	public int getCount() {
		return (dataSource != null) ? dataSource.size() : 0;
	}

	@Override
	public Object getItem(int idx) {
		return (dataSource != null) ? dataSource.get(idx) : null;
	}

	@Override
	public long getItemId(int position) {
		return  position;
	}

	@Override
	public boolean hasStableIds(){
		return true;
	}

	@Override
	public int getItemViewType(int pos){
		return IGNORE_ITEM_VIEW_TYPE;
	}

	@Override
	public int getViewTypeCount(){
		return 1;
	}
    }

While these methods look simple, they are used by the Adapter API to figure out how render the bounded views.  You can find more information about them from the SDK Android doc page for Adapter.

I hope this was helpful to your Android development efforts!  I have written enough.  Until next time!

Despite all the delays and the inevitable curve balls life throws at you (I had quite a few last and this year), the book is done.  Like anything worth doing its a gratifying feeling.  Now, let’s see if Oracle will come out with some extraordinarily good news for JavaFX  (at JavaOne 2010) to give wind to my JavaFX wings.

Go to http://www.javafxcookbook.com/ for how-to’s and tutorials and (if you don’t mind) pick up a copy of the book.  Thanks!

Besides multitasking there are some other nice features in 4.0 that I like:

• GUI Speed – that is the first thing you notice, things are snappier
• Folders – group application into folders
• App Tray – double click the home button and you get a list of currently running/paused apps that you can quickly switch from
• Camera – got nice update, simulated shutter speed is improved, digital zoom added
• Bluetooth – voice command works via bluetooth now

However, my excitement started to wear thin as I notice some annoyances that keep reoccurring:

• Phone Crash – the most annoying is the phone crashing.  Prior to 4.0, I never had to do a restart on my phone.  With 4.0 I had to do that 3 times already.  Sometimes in the middle of a conversation phone becomes unresponsive and must be restarted
• More frequent drop calls 
• Bluetooth transition slow – now, phone will ring first before it switch to my car

Conclusion: iOS4 is great, but wait for iOS 4.1 if you own the 3GS.  Hopefully that will address some of the issues I mentioned (actually the iPhone4 has its own set of bugs that 4.1 will also address, so just wait).

Today (in TechChruch), it was announced that Google is purchasing On2, the media compression technology company behind many of the most popular media codecs including FLV. This has the potential to change the course of online video technologies once again. One can only imagine some of the implications this purchase will have

• It moves Google higher in the media compression food chain and gives it complete control of the most popular codecs used on the web.
• Google may open source the current proprietary VP6 (on which Flash video is based) & VP7 codec formats that On2 licenses to companies. They may decide to provide needed support for the Ogg Theora format and make it first class citizen in the compression stack.
• With Google’s push of HTML5 which includes the notion of built-in video/audio support, one can rightly guess that we will see On2 technologies in Chrome Browser, Chrome OS, and Android and anywhere else Google control (which is wide and far).
• As Ogg (Vorbis and Theora) becomes the open source format of choice for media delivery, Google will wield its influence on the format and direction of media deliver on the web.

Why am I rambling about On2, Ogg, and video codec formats? Well, it all has to do with JavaFX. One of the selling point of JavaFX is portable playback of Video/Audio basedon VP6 (consequently FLV). With the purchase of On2, Google will have a direct control of the destiny of media codec supported by JavaFX. Depending on how Google proceeds, we, in the Java community, may see positive developments for JavaFX and this is how:

• Google open sources the On2 codec stack: big win for JavaFX (to a certain extent Adobe). This will imply that JavaFX applications can take part in the online media revolution with lowered entry points.We probably will see Java bindings to the codec’s API’s which means building both encoders and players in Java/JavaFX.
• If the stack is open source, this may also mean eventual support on JavaFX mobile platforms.
• Google may make On2 encoding tools available for free: another win for JavaFX! More videos being created with the supported On2 formats means more opportunities for JavaFX developers to create players.

Or, Google may decide to just sit on the technologies use them to further their ambitions in Mobile, desktop OS, and web markets. Only time will tell.

JmxLogger
JmxLogger makes it easy to broadcast your Java Logging or your Log4J log events as JMX notifications. As such, you can easily monitor your application’s activity logs in real-time. Using familiar logging API and configuration mechanism (i.e. log4j.xml or Java Logging properties file), developers can quickly integrate realtime application log monitoring into their existing deployed code. All it takes is a logging configuration change.

The JmxLogger API provides a Java Logging Handler and a Log4J Appender which can be used to integrate between your favorite logging framework and JMX. JmxLogger hides the complexity of dealing with JMX. You simply configure your logging framework as you normally do, and that’s it. You are ready to broadcast your logging events as JMX notification events.

Features

• Support for Java Util Logging API
• Support for the Log4J logging API
• Easy integration with your favorite logging framework
• No coding required, simply configure your logging framework to get started.
• Specify and control the level of event to broadcast
• Monitor event through a console or listener scripts
• Realtime monitoring of your application activity logging via JMX.

Getting Started

• Download the jar (generic or with log4j support)
• Add jar to your classpath (in case of Log4J, you will need log4j.jar on your classpath)
• Configure your favorite logging framework
• Use JMX console (JConsole or VisualVM) to monitor your log actvities.

JmxLogger Events

When you log your application events using either Java Logging or Log4J (see project site for more detail), your log events will get routed to the JmxLogger Java Logging Handler or Log4J Appender defined in your application’s logging configuration file.

Below you can see a configuration that sends log messages to the Console and a JmxLogger Logging Handler.

Using a command-line Console you can see your log message messages as they are logged in your application.

The same log events are also emitted as JMX notifications. Using JConsole, you can see these events as they are logged in your application in real-time.

That’s it! You have seen how JmxLogger can effortlessly integrate JMX and the two standard logging API’s available (Java Logging and Log4J).