Java - Setting context attributes (ServletContextListener)

Question

I read a properties-file at the webapplication startup phase (contextInitialized()) and I started to think about how to make these settings 'visible' to the servlets. Do I need to loop through the keys and add each and every one to the context, like this

Iterator i = settings.keySet().iterator();
while (i.hasNext()) {
 key = (String) i.next();
 value = (String) settings.get(key);
 context.setAttribute(key, value);
}

or are there better methods?

Thank you!

/Adam

Answer 1

Have you considered the possibility of defining the settings in web.xml?

Also, if that's not possible, use generics if possible:

String key = null;
Iterator<String> i = settings.keySet().iterator();
while (i.hasNext())
 context.setAttribute(key = i.next(), settings.get(key));

Answer 2

What about using the JNDI context. JNDI is a more common way to pass properties to a webapp.

Any Properties may be specified in the META-INF/context.xml for tomcat or any application specific setup.

Answer 3

why not store the entire contents in your servlet context?

context.setAttribute("mySettings", settings);

setAttribute's signature is:

public void setAttribute(String name, Object object)

Answer 4

It's something that I have contemplated, setting the entire properties object as a context attribute.

If I do not go this route, are there any guidelines for how to name these attributes or do you feel that "application.settings" or "myBlog.settings"? How do you group keys? Would this be okay:

application.module1.color=black
application.module1.font=arial

I feel, in a way, that it could become a burden to maintain such an application where the property keys are spread throughout the code? Should another developer rename a property in the properties file, we'll know only when running the application (if/when/what referenced the old key). Right?

I'll have to lookup JNDI.

Answer 5

I've been toying with an idea:

In the context initialized method, I've planned to create just one global object for the settings. Much like toolkit proposed. But instead of setting context attributes for each key/attribute/setting, would it be a terrible idea to add a settings container/wrapper object? I'm thinking this class would be responsible for holding (static?) classes of module settings. This way I can get typed references like so

//ExampleServlet.java
Settings settings = (Settings)context.getAttribute("application.settings");

String color = settings.getModule1().getColor();
String font = settings.getModule1().getFont();

int blogs = settings.getModule2().getActiveBlogCount();

Throughout the code I'll have to remember only one attribute key, the one for the entire settings container. Less risk of typos which could cause rumtime exceptions! It will also make it easy to rename attributes.

What do you think?

/Adam