CODEWITHSUNDEEP
javaspring
RockMeetHardplace
RockMeetHardplace

Reputation: 371

Best way to "merge" two ApplicationContext configurations

Here's the scenario:

I have a standard applicationConfig.xml spring configuration for a basic web app. It works great. I also have a "core jar" for one of our internal dependencies for a different app. The "core jar" has an AnnotationConfigApplicationContext which registers the different @Configuration beans appropriately. I'm trying to use the annotation @Configuration beans in the app which is configured using the applicationConfig.xml.

I can dream up two options which I believe will work:

  1. Refactor the xml config to also use the annotationConfig and register the different configurations to the context the same way our "core jars" do.

  2. Create a second context and access it directly instead of having the singletons/prototypes live on the same applicationContext as the xml config. I'd really rather not do this as it seems more like a hack than an elegant solution (and I'm not entirely sure it would behave as I'd want it to.)

  3. What I'm dreaming of, but can't find any documentation to support

I'd like to register the annotation configuration bean into the application context somehow, but I can't get the objects to line up the way I'd like them to (aka, my context won't .register() the @Configuration file - only 1 bean at a time....)

Just to follow up - I got this working (YAY). In my case, I ended up following the general pattern set forth by gpeche.

The applicationContext-parent.xml contained the 1 bean def:

<bean id="parentApplicationContext" class="org.springframework.context.annotation.AnnotationConfigApplicationContext" scope="singleton">
    <constructor-arg>
      <list>
        <value>com.package.CoreCommonInContainerConfigImpl</value>
        <value>com.package.CoreCommonCommonConfigImpl</value>
      </list>
    </constructor-arg>
</bean>

where the CoreCommon****Impl classes are @Configuration annotated classes which define beans for that context.

As gpeche noted, an @Autowired Bean bean; inside of a controller (for example) falls back on the parent context and resolves automagically.

THANKS!

Upvotes: 2

Views: 6224

Answers (1)

gpeche
gpeche

Reputation: 22524

What I would do:

1) In my WAR, put an additional Spring context file, say applicationContext-parent.xml.

<beans ...>
    <bean id="parentApplicationContext" class="org.springframework.context.annotation.AnnotationConfigApplicationContext" scope="singleton">
    <!-- Any other configuration for your annotation-configured context -->
</beans>

2) Specify this in my web.xml:

<!-- Where do I have my parent context? -->
<context-param>
    <param-name>locatorFactorySelector</param-name>
    <param-value>path/to/applicationContext-parent.xml</param-value>
</context-param>

<!-- How is my parent context called? -->
<context-param>
    <param-name>parentContextKey</param-name>
    <param-value>parentApplicationContext</param-value>
</context-param>

With this configuration, you will have parent/child contexts and not a "real" merged context, but you should be able to inject beans from the parent context into child context beans in the usual way, the child context will fall back to the parent context when trying to resolve beans.

Upvotes: 5

Related Questions