Home/ Questions/Q 692807
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T02:41:20+00:00

I have a spring-based Web Service. I now want to build a sort of

  • 0

I have a spring-based Web Service. I now want to build a sort of plugin for it that extends it with beans. What I have now in web.xml is:

<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>/WEB-INF/classes/*-configuration.xml</param-value>
</context-param>

My core app has main-configuration.xml which declares its beans. My plugin app has plugin-configuration.xml which declares additional beans. Now when I deploy, my build deploys plugin.jar into /WEB-INF/lib/ and copies plugin-configuration.xml into /WEB-INF/classes/ all under main.war.

This is all fine (although I think there could be a better solution), but when I develop the plugin, I don’t want to have two projects in Eclipse with dependencies. I wish to have main.jar that I include as a library. However, web.xml from main.jar isn’t automatically discovered. How can I do this? Bean injection? Bean discovery of some sort? Something else?

Note: I expect to have multiple different plugins in production, but development of each of them will be against pure main.jar

Thank you.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think there is a simpler approach:

    In your host application (the webapp) define something like the following contextConfigLocation parameter:

    <context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>classpath*:/META-INF/foo/*-configuration.xml</param-value>
</context-param>

    The crucial parts are classpath*:as it results in scanning the entire classpath for config files matching the following pattern. If you only use classpath: the lookup will stop at the first file found. It also won’t traverse JARs if not starred correctly.

    The second crucial part is having at least one non-wildcarded basepath for the lookup to work. This is due to Classloader traits that only reliably returns all resources if they contain a base path (see the Javadoc on PathMatchingResourcePatternResolver for details).

    What you now have to do with your plugin projects is place your plugin-configuration.xml in /META-INF/foo/, package that as JAR and place it into your classpath (in case you build with Maven just add the dependency).

    On application start Spring will now also pickup all config files from your plugins and build the ÀpplicationContext` from em.

    You also might wanna checkout another post I did on application modularity with Spring: How do you make a multi-module spring configuration?

    • 0