As you may have suspected, the answer is "Yes". :-) Spring configuration files are meant to be highly modular, so I'll describe best-practice in general, and then you can see the specifics for this...
(Caveat at the start: If it's a trivially simple application, then of course it really doesn't matter. But if it's non-trivial then understanding the "whys and wherefores" becomes important.) One of the principle ways that you separate configuration is between "application" level objects (services et-al) and infrastructure (eg, DataSources). Among many other benefits, this allows you to easily re-use configuration for different environments (Dev vs. Prod, mocked-infrastructure for testing, shared services, etc). In the case of Spring MVC, it makes use of a more "advanced" feature for firewalling responsibilities: ApplicationContext hierarchies. Because in good design you want your View layer to know about your Business layer, but your Business layer to be completely ignorant of the View layer, it creates the View objects (controllers and the like) in a separate ApplicationContext that is a child of the AppCtx that has the business objects. (Thus the distinction between "contextConfigLocation" for the root AppCtx and the AppCtx created by the Dispatcher servlet that uses the "*-servlet.xml" convention.) So the objects that you'd put in the root AppCtx would be in resources/ (the the "classpath:" resource loading prefix) and the objects you'd put in *-servlet.xml would be in WEB-INF. (With lots more options for different needs; and that doesn't even start getting into all the power that going to an OSGi approach gives... ;-) Hopefully that explained more than it confused. J -Jim Moore On Sun, Dec 20, 2009 at 6:40 PM, Roger Studner <[email protected]> wrote: > If I'm building up a war etc with gradle.. is the proper convention to put > spring XML files in the src/main/resources (what i'm doing now), or in > src/main/webapp/WEB-INF? > > "convention" :) > > Roger > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
