Hi,
I have a few applications which consist of a few modules.
Some modules can be shared between applications (i.e. all apps share a common "utils" module) - their output are jars.
Others are end-application modules (i.e. containing the gui and application core) - their output are wars.
Now I'm wondering what the best approach to loading application context for this type of apps is.
It seems to me that it would be best for each module to have its own piece of the whole application context (configuration of that module's beans etc.) along with a *.properties file for that piece of application context.
The end-app (war) has a dependency on a given jar. Inside the war's application context I can have an import statement like so:
which loads the jar-module's context. I think it would be most convenient to just add the line above and not worry about anything else. In particular all the jar-module's configuration properties are already defined inside its *.properties file. But on the other hand if I want to override a jar-module's property I can do so inside the end-app *.properties file. This could be achieved by something like this:Code:<import resource="utils-context.xml"/>
Inside the jar-module's (utils) context I have:
Inside the end-app's context I have:Code:<context:property-placeholder location="classpath:utils.properties" />
This way the properties will be first loaded from end-app.properties but any missing ones will be loaded from utils.properties.Code:<context:property-placeholder location="end-app.properties" ignore-unresolvable="true" /> <import resource="classpath:utils-context.xml"/>
What do you think? The above seems like a good idea to me, but perhaps there are other (better?) ways to achieve this. Or some good practices?
Thanks,
Piotr


Reply With Quote
