For a Spring webapp with pure Java config, does it make sense to have 2 distinct contexts? -

i new spring java config, , wondering something.

traditionnally spring webapps have had 2 different contexts, root application context , dispatcher servlet context. root context contains service layer (persistence configuration jpa , data access layer) , servlet context containing mvc , other web-related things.

the web context inherits root context, web components have access beans in root context not opposite.

with modern approach using xml-less config , org.springframework.web.webapplicationinitializer, still make sense have 2 different contexts ?

it seem simpler have few annotated @configuration classes regrouping beans layer (e.g. 1 data access layer, 1 service layer, 1 web layer) , load of them in same context, :

public class mywebapplicationinitializer implements webapplicationinitializer {      @override     public void onstartup(servletcontext container) {          // create dispatcher servlet's spring application context         annotationconfigwebapplicationcontext dispatcherservletcontext = new annotationconfigwebapplicationcontext();         dispatcherservletcontext.register(mypersistenceconfig.class, myservicesconfig.class, mymvcconfig.class);          // register , map dispatcher servlet         servletregistration.dynamic dispatcher = container.addservlet("dispatcher", new dispatcherservlet(dispatcherservletcontext));         dispatcher.setloadonstartup(1);         dispatcher.addmapping("/");     }  } 

however have seen examples root context still created, , lifecycle managed using org.springframework.web.context.contextloaderlistener :

public class mywebapplicationinitializer implements webapplicationinitializer {      @override     public void onstartup(servletcontext container) {          // create 'root' spring application context         annotationconfigwebapplicationcontext rootcontext = new annotationconfigwebapplicationcontext();         rootcontext.register(mypersistenceconfig.class, myservicesconfig.class);          // manage lifecycle of root application context         container.addlistener(new contextloaderlistener(rootcontext));          // create dispatcher servlet's spring application context         annotationconfigwebapplicationcontext dispatcherservletcontext = new annotationconfigwebapplicationcontext();         dispatcherservletcontext.register(mymvcconfig.class);          // register , map dispatcher servlet         servletregistration.dynamic dispatcher = container.addservlet("dispatcher", new dispatcherservlet(dispatcherservletcontext));         dispatcher.setloadonstartup(1);         dispatcher.addmapping("/");     } } 

for simple webapp (single maven module), second approach bring concrete benefits balance complexity ? best practice ?

you asking advices, not far opinions. answer i have understood of spring philosophia.

spring allows use different contextes non mvc part , mvc part , advises so, because separation of concerns (*) considered practice. never force developper it.

you can put in single context in java configuration, same can xml

it know if pseudo-rule (2 contextes) relevant application. if later move spring mvc framework, is relevant. if working in large organization different developpers work on mvc part , on non mvc part, is relevant. if simple application, 1 single developper, , little expected evolutions, can exchange best practices against simplicity.

rules guidelines, , developpers must know when must followed, , when can ignored. , depends on general context, size of project, of organization , general experience.

(*) separating model part (service , persistence) vc part (user interface) considered because :

• you can (in theory) change ui part while keeping model part (migration traditionnal webapp fat client changing ui minimal restfull interface)
• you can develop , test different layers little adherence possible
• you can have different teams on model , viewcontroller parts neat separation of responsabilities
• it may enforced corporate rules