0

The application I am working on has an XML-based Spring configuration(framework version: 4.1.7.RELEASE).

Because I want to instantiate certain beans provided a profile is specified, I have added the following to my web.xml:

 <servlet>
        <servlet-name>my-app</servlet-name>
        <servlet-class>
            org.springframework.web.servlet.DispatcherServlet
        </servlet-class>
<!-- This part is new -->
        <init-param>
            <param-name>spring.profiles.active</param-name>
            <param-value>${spring.profile}</param-value>
        </init-param>
<!-- End of newly-added part -->
        <load-on-startup>1</load-on-startup>
    </servlet>

spring.profile is a property set in the Maven pom.xml, based on the Maven profile that is selected:

<profiles>
    <profile>
        <id>dev</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <spring.profile>development</spring.profile>
        </properties>
    </profile>
    <profile>
        <id>prod</id>
        <properties>
            <spring.profile>production</spring.profile>
        </properties>
    </profile>
</profiles>

I have filtering enabled in my maven-war plugin, which works as expected, because the placeholder is replaced with the appropriate value based on the Maven profile chosen. Therefore, the part involving Maven is cleared and works fine.

However, when I try to inject an Environment instance, the active profile list is empty:

@Autowired private Environment env;
...
log.info(env.getActiveProfiles().toString());

The servletConfigInitParams appears in the list of property sources for the Environment, but it seems that my init-param is simply ignored.

I have managed to set the Spring profile by providing actual system properties in the two maven profiles and running with those set, but that is not a viable solution for the production environment, nor would it be to provide those through command line.

Can anyone tell what I'm doing wrong?

Cristina_eGold
  • 1,463
  • 2
  • 22
  • 41
  • Is the list null or the `env`? Are you injecting this into a sprig managed bean or in something that you create yourself with `new`? Also imho creating different war files per environment is a bad thing, you are basically putting untested code into production as it is a different artifact. – M. Deinum Apr 15 '16 at 09:02
  • Neither is null. The list is empty, the NPE comment was a mistake on my part. Of course, the bean I am injecting the `env` in is Spring-managed. The `production` artifact needs to be slightly different than the development one, because the setup is different (different server technology, different DB requirements). However, that is the artifact that is tested in the release cycle: functional testing, system testing, integration testing, user acceptance testing and so on, so have no fear, the build doesn't jump to production so easily. – Cristina_eGold Apr 15 '16 at 09:09
  • And is this bean in the `DispatcherServlet` or part of the `ContextLoaderListener` or accidentally both... – M. Deinum Apr 15 '16 at 09:16
  • I think it's part only of the `ContextLoaderListener`, as it is specified in the xml corresponding to the `contextConfigLocation` context-param – Cristina_eGold Apr 15 '16 at 09:26
  • That will not have access to the environment set on the `DispatcherServlet`. Hence it doesn't know anything. If it is global instead of an `init-param` define it as a `context-param` like the `contextConfigLocation`. – M. Deinum Apr 15 '16 at 09:30
  • Should have probably mentioned that I've already tried that (but without knowing the actual difference, so thank you very much for the explanation), but to no avail. It still can't see any active profiles. – Cristina_eGold Apr 15 '16 at 09:32
  • Show the bean where you are adding the `Environment` not only a snippet. And make sure it is a context-param else it will never work for beans declared in the root context... – M. Deinum Apr 15 '16 at 09:34
  • Actually, I tried moving it up in the web.xml, just above the contextConfigLocation config-param, and it now works. I didn't think the order of the context-params mattered in any way, but it seems it does. Thank you for the great help! Please add the solution as an answer, so that I can mark it as accepted answer. :) – Cristina_eGold Apr 15 '16 at 09:37

0 Answers0