Thursday, October 20, 2011

Using Environment Entries with WebSphere

I just spent the last few days trying to find an easy way to configure my web services deployed as annotated POJOs and I think I've found it. The idea is to provide an easy mechanism to change values through the administration console and have the java code pick up those changes at run time without redeploying. I thought about using a property file but this is inconvenient because we have a clustered environment and editing files in a deployment directory isn't the best idea.

@Resource Saves the Day
Anybody who used JNDI before the days of annotations knows that old style lookups were a little bit of a pain, but maybe I’m just being difficult. Here’s how I got it working - first thing is to add the proper entries in my web.xml:
<web-app...> ... <env-entry> <env-entry-name>DsixE/SomeParameter</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>This really rocks</env-entry-value> </env-entry> ... </web-app>
Next I add an annotation to my code:
    @Resource(name="DsixE/SomeParameter")
    private String someParamter;
I build a WAR, deploy it to WebSphere and notice that I have a new entry in the administration console:


…. which allows me to change the value at any time:


Now the container injects the value defined into member variable someParameter at run time. This is the first time I’ve really used an <env-entry> so I guess this old dog can still learn new tricks.


Please note that generic comments containing links with the intent of self promotion will be flagged as spam and deleted.

1 comments:

  1. I can't believe this post has no previous comments about how useful it is. I love this kind of brevity too

    ReplyDelete

Are you about to post a generic comment that has nothing to do with this post? Something like "Hey thanks for this very valuable information, BTW here's my website". If so, it will be marked as spam and deleted within 24 hours.

Note: Only a member of this blog may post a comment.