简体   繁体   中英

Java, configure enterprise application and web application with spring: should they share the spring context?

I have an event-driven application based on spring-integration. The application is made up of 4 modules: domain (model objects), persistence (daos), core (biz logic based on spring-integration) services (MDB).

Every module is a maven project. The application is packaged in a EAR and deployed on weblogic.

The spring context is shared among all the modules.

Now I have to develop a web-application to expose a subset of the domain: so my controllers should use some daos and some domain objects. What is the best practice to handle this problem? Should the web application share all the ear spring context? Or is better to create a "ad hoc" web application spring context where I redefine all what I need? (eg daos).

Seems like you would benefit from a functional layering, eg instead of

|- persistence (daos)
|- domain (model objects)
|- core (biz logic based on spring-integration)
|- services (MDB)

You could layer your application in a functional way. Let's say your app does trading:

|- broker
|- product
    |- underlying
    |- option
    |- future
    |- forward
    |- ..
|- feed 
|- valuation
|- ...

Under broker you would have broker-persistence , broker-service , etc.. Of course the business domain of your app is probably different, and this is a naive example, but it illustrates the point.

This way you can still include everything in your EAR , with a lot greater flexibility on what can be included/imported into you webapp.

For example, you can even create a broker.war separate from a product.war . Which also means that you can redeploy a broker.war without bringing down the product.war . You may not need it in your business domain, but it is a nice ability to have, which can only be reached when things are layered according to the business need/area, rather than a tech stack.

By the way no need to complicate things with EAR just for MDBs, you can use Spring's Message Driven POJOs which will be simply controlled by a Spring container.

Normally, you create a specific WebApplicationContext for each DispatcherServlet in which you put all web related stuff, eg controllers, handlermapping, viewresolvers, etc. The rest of your application context(s) eg services, daos, etc, is / are configured in a root WebApplicationContext that is shared by all servlets.

Example web.xml :

<web-app ...>

    <!-- Definition of the root web application context and shared by all servlets -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/dao-config.xml,/WEB-INF/other-config.xml</param-value>
    </context-param>

    <!-- Must be added to enable the configs above -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

    <!-- Servlet specific application context that inherits bean definitions from the root application context. By convention, it is located in in /WEB-INF/[servlet-name]-servlet.xml -->
    <servlet>
        <servlet-name>yourservlet</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>yourservlet</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>

</web-app>

Scroll down to the picture "Context hierarchy in Spring Web MVC" in the Spring MVC Reference Documentation for overview and more details.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM