PropertySetter#process(..) is the entry point to traverse the variables of an object/class – see my original post for an example.

Most of my projects involve Spring, but a few small ones don’t and I don’t want to have to a) use Spring or b) set the properties and do the type conversion by hand – that’s where objectify-led (need to find a shorter name…) comes in handy.

One other advantage (which I haven’t written yet) is automatic help generation on the command line. Since all properties which can be set are annotated, they can automatically be discovered and printed out. Hope to get around to implementing this at the weekend.

there’s nothing too spectacular in this class. But when and how is PropertySetter#process(..) invoked? But don’t get me wrong. Your project looks nice. However, it’s mostly a subset of Spring’s functionality – and Spring is what I’m already using on a daily basis.

I know that my enum isn’t suited for project-specific properties. That never was it’s intention. I’m not even sure about using an enum. But the “how” is not important anyway. My main objective was documentation on the one hand and getting rid of string constants on the other hand. Both in order to leverage IDE capabilities such as autocompletion and inline Javadoc.

take a look at http://objectify-led.googlecode.com/svn/trunk/src/main/java/be/objectify/led/PropertySetter.java and you’ll see how the annotations are processed.

I like your approach for well-known properties, but for arbitrary properties it would require either the developer to update the class manually and then have to merge in your future updates, or for you to add properties from potentially proprietary projects to the enum.

Personally, I would (and will) use your SystemProperty enum for well-known props (don’t re-invent the wheel!) and objectify-led for project-specific properties.

First, sorry that I’ve forgotten to approve your comment yesterday. Personally, I’m not interested as I’m normally using Spring for what you describe. And if not, compared to

@Property(“user.country”);
private String country = “US”;

using

private String country = SystemProperty.USER_COUNTRY.get(“US”);

looks far less … frightening

How do you process the annotations? I couldn’t find that information on your site.

thanks for your input. I’ve added the get(String) method. Additionally, I’ve added some convenience methods that convert the String: getInteger(String), getLong(String), getBoolean(String), getFloat(String), getDouble(String), getFile(String) (all with a no-argument alternative and a corresponding setter).

I’m also thinking about uploading the result as a Maven artifact as soon as my work is done. This way, it can easily be included in any project.

It handles assignment of properties using, amoung other things, system properties, properties files or arbitrary data sources. Type conversion is also handled.

public class Foo
{
@Property(“blah.value”);
private static String BLAH = “default-value”;

@Property(“mystring.value”);
private String myString;

@Property(“myint.value”);
private int myInt = -1;

public static void main(String[] args)
{
Foo foo = new Foo();
new PropertySetter().process(foo);
}
…
}

It allows to specify the default value to return when the value of the property is null. It calls:
System.getProperty(getName(), defaultValue);

-Christopher

“sun.awt.disableMixing” (for Sun VM on Java 6u14+)
“sun.awt.noerasebackground”
“sun.awt.xembedserver”

By-the-way, I love this idea of an enum for all properties, and I will probably create a similar enum for my application-specific properties!

Keep up the good work.
-Christopher