Announcement Announcement Module
Collapse
No announcement yet.
Spring, Struts and ApplicationContext Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring, Struts and ApplicationContext

    Hi,

    I have read the Spring and Struts integration article and also tried a few sample applications. Although I managed to get the application works, I am still confused on the WebApplicationContext part. After Spring integrated with Struts, the applicationContext is initialized via

    Code:
    <plug-in className="org.springframework.web.struts.ContextLoaderPlugIn">
    <set-property property="contextConfigLocation" value="/WEB-INF/conf/applicationContext.xml" />
    </plug-in>
    However, if we add a Context Listener at Web.xml and assign the contextConfigLocation as below, will there be two applicationContext initialized?

    Code:
    	<context-param>
    	    <param-name>contextConfigLocation</param-name>
    	    <param-value>/WEB-INF/conf/applicationContext.xml</param-value>
    	</context-param> 
    	<listener>
    	    <description>Spring context loader</description>
    	    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    	</listener>

  • #2
    You will indeed get 2 instances of your context and all beans.

    Comment


    • #3
      Originally posted by Marten Deinum View Post
      You will indeed get 2 instances of your context and all beans.
      Thanks for the reply. In this case, I will have the AXIS web service on the Spring layer, and my application is on the Struts layer.

      The AXIS webservice requires the ContextLoaderListener in web.xml. I guess the only approach to have two different instance if I need to use the existing managers such as DAO etc.

      Comment


      • #4
        The ContextLoaderPlugin detects an already loaded context by the ContextLoaderListener. So you can simply load all your daos, services etc. with the ContextLoaderListener and only the web stuff by the ContextLoaderPlugin...

        SO you don't have to duplicate your beans you simply have to move them to the correct context.

        Comment


        • #5
          Originally posted by Marten Deinum View Post
          The ContextLoaderPlugin detects an already loaded context by the ContextLoaderListener. So you can simply load all your daos, services etc. with the ContextLoaderListener and only the web stuff by the ContextLoaderPlugin...

          SO you don't have to duplicate your beans you simply have to move them to the correct context.
          In this case, what will happen for beans with similar names, lets take the following as an example.
          In strut-config, I have declared
          Code:
          	<bean id="myService" class="com.acme.myService">
          		<property name="daoManager" ref="daoManager" />
          		<property name="securityManager" ref="securityManager" />
          		<property name="UIManager" ref="UIManager" />
          	</bean>
          But in the ApplicationContext, I only require daoManager, so I just include the daoManager.
          Code:
          	<bean id="myService" class="com.acme.myService">
          		<property name="daoManager" ref="daoManager" />
          	</bean>
          Assuming I must use the same bean id because it is tightly couple. In this scenario, which will be loaded?

          Comment


          • #6
            I suggest a read of the reference guide, the chapter explaining contexts and hierarchies.

            It depends.. It depends on how you load your xml files, you shouldn't include all the xml files in the ContextLoaderPlugin but only the xml for struts configuration. Both the CLL and CLP will have an instance of an ApplicationContext (the CLL one will be treated as a parent for the CLP one). When a bean is requested first the child is consulted for a bean with name x, if it isn't there the parent is consulted. So if both beans are in separate contexts there is no problem... HOwever if both xml files are loaded in the same context there will be only one instance of the bean (the last one loaded will override the earlier loaded/defined beans).

            For a more elaborate explanation I suggest the reference guide.

            Comment

            Working...
            X