Do you mean, use a context init param instead? I think the reason it was done this way was to enable reading in all these settings via a Properties object and then populating the bean properties. I'm not quite following you.
My question is simple: what is the purpose of the constants in the Constant class?
It's not all clear from what you're posting, and I'm having a hard time not seeing a huge anti-pattern red flag waving.
If the answer is: to provide run-time flags, then a constant class is a huge anti-pattern. Use a properties file. Easily read by a context listener and stored as a Map in app context where the EL can easily access it.
Joined: Jan 20, 2008
OK, I more or less understand. I've been looking at this code and trying to understand why we need a class at all if it's just a big wrapper for a Properties object, and I could not come up with anything. This code was done a long time ago.
Updating a web app to move away from scriptlets and to the JSTL/EL is almost never as easy as a line-by-line substitution, unfortunately. There's usually some refactoring involved and this is a perfect example.
As previously mentioned, the approach I'd take is to put the values into a properties file and read them in in a context listener. Store the name/value pairs in a Map in app scope. Then it's trivial to access the values from anywhere in the app, including the JSPs.
It's not only a clearer, more conventional approach, but it doesn't require code changes and rebuilding to change the values.