ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Using PASX

by Andrew Newton

Have you ever written a program, only to look back upon it and find dissatisfaction with its configuration process? Have you ever used properties files, only to find that they are not expressive enough for you needs? Have you ever created a small configuration hack to solve some specific problem, only to later wish you had spent more time on a generic solution?

If you answered "yes," then you are like most Java programmers and, fortunately for you, there are tools to help solve these problems. If you answered "no," then perhaps a discussion on the limitations of properties files will convince you that there are better ways.

Properties files are a mainstay of the Java programming and execution environment. But once a programmer needs to get beyond the simplicity of name/value pairs offered by the Properties class, there is a need for more expressiveness. Often, Java programmers attempt to extend properties files by attaching extra semantics to the names or values (or both) of the properties themselves. And often times this is the slippery slope that starts off as a minor dip and ends up a rather large chasm.

To illustrate, try using properties to assign a list of values to a single name. Let's say you wanted to keep track of a set of nameservers. You might try something like this:


That was simple enough. By overriding the meaning of the name, you can easily write a program that understands that all property names beginning with "hosts_" are but a single element in the list "hosts."

Now let's make things a little trickier. Imagine that you have two separate instances of the same Bean class called InternetHost. Instance A is to be concerned with a list of web servers, while instance B is to be concerned with a list of name servers. To configure both instances from the same file, one solution might be as follows:


Well, that works, but it is a kludge. If you are still not a believer then try cranking up the complexity just a little more: try making one of the elements in these lists into a list of its own, or try making the list of name/value pairs into a map of name/value pairs where the underscore ("_") character is legal. Your simple properties file has now become very complex.

Comment on this articleWhat are your open source tool solutions? Do you use PASX or an alternative to it?
Post your comments

Being an observant reader, you probably also noticed that the naming of the individual instances of InternetHost was gently side-stepped and not addressed in the last example. To truly assign the first three properties to instance A and the second three properties to instance B, you must somehow tell the instances which set they are to use in an instance-independent manner. If instance A were hard-coded to look for property names starting with name_, and instance B were hard-coded to look for property names starting with web_, then the two instances would not be of the same object class.

Finally, this last example also brings up another point. Just what do you call instance A? Is it simply "A"? Where do you go to find it? Is it a local instance or just a remote interface? Is there a globally static reference to it? If so, how do you get to instance B (or is that "B")?

The solution to these problems is to use a component configuration and naming framework. There are many tools to aid you in this task, and one of these tools is PASX. PASX is an open source tool for Java utilizing XML for configuration and JNDI for naming.

Pages: 1, 2, 3

Next Pagearrow