2013-10-23 36 views
0

我试图设置我的Spring应用程序,以便根据配置文件读取不同的.properties文件。我用java配置等什么,我试图做的是这样的:如何将环境自动装入PropertySourcesPlaceholderConfigurer?

@Autowired 
private static Environment env; 

@Bean 
public static PropertySourcesPlaceholderConfigurer properties(){ 
    PropertySourcesPlaceholderConfigurer pspc = new PropertySourcesPlaceholderConfigurer(); 
    String[] profiles = env.getActiveProfiles(); 
    String filestring = "environment."+profiles[0]+".properties"; 
    ClassPathResource properties = new ClassPathResource(filestring); 
    Resource[] resources = new ClassPathResource[] { properties }; 
    pspc.setLocations(resources); 
    return pspc; 
} 

然而env.getActiveProfiles()是给我一个NullPointerException,我以为意味着环境尚未注入。任何人有任何想法,我怎么能解决这个问题?或者,如果这是愚蠢的/不可能的我怎么能更好地做到这一点?

回答

0

只是为了给你一个关于你的方法的替代视角(显然每个人的商业案例可能因项目而异),但是你所追求的配置类型可能会导致其他令人头痛的问题。安全浮现在脑海。通常多个环境意味着您正在处理与数据库等的各种连接的用户名和密码。将生产环境中的这些值存储为与其他配置一致可以将敏感数据暴露给需要不知道这些事情的开发人员。相反,如果您切换使用SPeL表达式并直接引用环境,那么您仍然可以实现运行时配置,但将每个环境的设置移动到适用于特定配置的服务器(或者您所拥有的)。例如:

<bean id="myDatabase" class="mypackage.MyDatabase" p:username="#{environment['DB_USERNAME']}" p:password="#{environment['DB_PASSWORD']}" .../> 

然后在服务器上,你可以通过在系统属性或设置环境变量与所需的用户名和密码,他们会在运行时进行配置。 (environment表达式直接解析为您的Environment实例。)

只是一个想法。 =)

0

作为@kungfuters正确地建议,商业案例可能因应用程序而异。这是另一个适用于我的应用程序的替代方案。

提供以下接口的实现:

ApplicationContextInitializer<ConfigurableApplicationContext> 

提供实施下列方法的。识别配置文件的逻辑就是采用这种方法。

initialize(ConfigurableApplicationContext ctx) 

基于该识别,设置活动简档:

this.applicationContext.getEnvironment().setActiveProfiles(<<yourProfileName>>)