Markus Eisele

About Markus Eisele

Markus is a Developer Advocate at Red Hat and focuses on JBoss Middleware. He is working with Java EE servers from different vendors since more than 14 years and talks about his favorite topics around Java EE on conferences all over the world. Follow him on Twitter @myfear.

Configure Java EE applications or “Putting Bien into practice”

A lot has been talked about application configuration in the past. I don’t know who kicked off the debate but the most fundamental reading (with a look at future Java EE 7 and beyond) is Antonio Goncalves’ posting [Debate] – And what about configuration in Java EE 7. Fact is, with vanilla Java EE we all do application configuration day by day. Without having any special mechanism in place. Having seen Adam’s latest post from yesterday I would like to share a slight add-on to it, which I feel could fit to most of the projects out there.

Why this post?

The basics shown by Adam are really smart. You simply

@Inject
int yourConfigVariable;

and you are done. You don’t have to care about properties or other configuration classes. But looking into it, you see, that you somehow need to fill your configuration from somewhere. And looking back at Antonio’s post, you see that you have a lot of options doing this. The one we are most comfortable with is probably Java’s Properties mechanism. Using this in combination with the code presented by Adam you end up having a Configuration.properties with an endless list of single word keys. That’s not what I would call maintainable. So basically this is why the post has the title: “Putting Bien into practice” ..oO(sorry for that, Adam!) :-) Here are my approaches to the problem.

Fill your configuration from a properties file

The most basic part is to add a Configuration.properties file to your application (default package). Now we are going to modify the configuration holder a bit to make it a Properties type. Now modify Adam’s fetchConfiguration() method to load it.

private Properties configData;

@PostConstruct
    public void fetchConfiguration() {
    String fileName = "Configuration.properties";
            configData =
                    loadPropertiesFromClasspath(fileName);
}

     /**
     * Load properties file from classpath with Java 7 :-)
     * @param fileName
     * @return properties
     */
  public static Properties loadPropertiesFromClasspath(String fileName) {
  try (InputStream in = Thread.currentThread().getContextClassLoader().getResourceAsStream(
                        fileName)) {
            if (in != null) {
                props = new Properties();
                props.load(in);
            }
        } catch (IOException ioe) {
            log.debug("Can't load properties.", ioe);
        }

Now you have to modify the @Producer methods accordingly. I’m only showing the getString() method here to show you the concept:

/**
     * Get a String property
     * @param point
     * @return String
     */
@Produces
public String getString(InjectionPoint point) {
        String propertyPath = point.getMember().getDeclaringClass().getName()+ ".";
        String propertyName = point.getMember().getName();
        String propertyValue = configData.getProperty(propertyPath+propertyName);
        return (propertyValue == null) ? "" : propertyValue;
    }

For convenience reasons I added the name of the declaring class as propertyPath in order to have a bit more order within your property file. You use the producer methods as Adam has shown:

package net.eisele.configuration;
public class HitsFlushTimer {
    @Inject
    private String hitsFlushRate;
 }

In this case you end up accessing a property with the key net.eisele.configuration.HitsFlushTimer.hitsFlushRate in your Configuration.properties file. One quick warning. If it happens to you, that you have to package separate ejb and war modules within an ear you probably need the javax.annotation.security.PermitAll annotation at your Configuration singleton.

Then you end up with lots of duplicates

That’s probably true. If you have the same configuration over an over again (e.g. httpProxy) this would force you to have the same value for different keys in your property file. The solution seems straight forward. We need our own Qualifier for that. Let’s go:

@Retention(RUNTIME)
@Target({FIELD, METHOD})
@Qualifier
public @interface AppProperty {
    @Nonbinding
    public String value();
}

Now we have our own Qualifier for that. Next is to change the @Producer accordingly:

@Produces @AppProperty("")
    public String getString(InjectionPoint point) {
    String property = point.getAnnotated().getAnnotation(AppProperty.class).value();
    String valueForFieldName = configData.getProperty(property);
    return (valueForFieldName == null) ? "" : valueForFieldName;
}

That’s it. Now you can use something like this wherever you like:

@Inject
    @AppProperty("net.eisele.configuration.test2")
    String test2;

I know, this isn’t half that elegant like Adam’s one @Inject annotation. But:You don’t have to guess a lot to see what’s happening and where your value is coming from. I consider this a big pro in projects with more than one developer.

Yeah. Still not very maintainable.

Ok. I know. You are still talking about refactoring property names. Right? What is left to do? You could think about using a CKey Enum which encapsulates all your property keys and use this instead of simply using the keys itself. But, I would prefer to simply use the plain String keys within my code. Happy configuring now. How are you configuring your applications? Let me know! Happy to receive comments :)

Reference: Configure Java EE applications or “Putting Bien into practice”  from our JCG partner Markus Eisele  at the Enterprise Software Development with Java blog.

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


4 + = thirteen



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close