0

I am in the basic stages of writing a Spring3 MVC webapp with Hibernate. I want all of data model classes to be able to access basic configuration values for example, database table prefix name, etc. I want this option, so I (or other developers) can change things on the fly by modifying them in the .properties file.

Is my best bet to create a Config class in a util package with a static block that loads a bunch of properties from a .properties file? I suppose the class itself could be static with a variety of getters to access the values within.

If I choose the method above, how could I insure the application didn't load (Failed gently) if for some reason the .properties file I have specified was not able to be loaded? With exceptions?

If my way stinks, what might be a better scenario?

Thanks!

tereško
  • 58,060
  • 25
  • 98
  • 150
Sam Levin
  • 3,326
  • 7
  • 30
  • 44

1 Answers1

1

That's a fine approach IMHO. If you would explicitly declare a bean for this class, like

<bean id="myConfig" class="com.yourcompany.yourproject.Config"/>

spring will fail at startup if it cannot instantiate the bean. So if the properties file is unreadable/not available just throw an unchecked Exception from Configs constructor.

if -for some reason- you enabled lazy loading globally you have to explicitly disable it for this bean, otherwise you won't get a failfast solution

<bean id="myConfig" class="com.yourcompany.yourproject.Config" lazy-init="false"/>

EDIT: another nice feature of this scenario is that you can tell maven to 'filter' the resource (the .properties file), and you can get all the maven variables. This is how my prop file looks (I use this info for the About dialog. Does anybody ever opens an about-dialog btw?)

project.version=${project.version}
project.name=${project.name}
project.organization.name=${project.organization.name}
project.url=${project.url}
project.description=${project.description}
Gergely Szilagyi
  • 3,813
  • 1
  • 14
  • 12
  • This is nice. After the exception is thrown in config initializer, spring shuts down automatically, or I must catch the exception and do system.exit? Sorry for the confusion - I haven't quite made it that far with Spring yet, I'm still on the ORM layer. – Sam Levin Jun 27 '12 at 13:03
  • It'll be handled by spring. If it's an app server then the app deployment will fail, if it's a standalone app it will exit. – Gergely Szilagyi Jun 27 '12 at 13:09
  • app-server... yes, sounds interesting.. any good reads on that? – Sam Levin Jun 27 '12 at 23:59
  • just google for JBoss, Glassfish, IBM WebSphere, etc.. Mostly I use Glassfish, partly because it's free, partly because of subjective taste. YMMV – Gergely Szilagyi Jun 28 '12 at 16:53
  • Where is the exception caught ultimately? What do I do in the "catch" block to exit? How does Spring know not to load the bean, and therefore, not the app? I plan on using Tomcat 6 or 7. Thank you – Sam Levin Jun 28 '12 at 23:27
  • @SamLevin: Spring will catch it. Your exception will 'bubble-up' the stack, all the way to Spring. (This is why it has to be an unchecked exception, something derived from RuntimeException) The 'magick-trick' what spring does is letting it bubble-up more. In the case of an application that means the runtime will catch it and exit the program. (you can test it with a simple nullpointerexception) In the case of the appserver: an uncaught exception in the __deployment phase__ means, that the deployment has failed. What to do to exit? Catch the checked exception and throw an unchecked one instead – Gergely Szilagyi Jun 28 '12 at 23:35