在一次战争中有多个CDI配置配置文件(开发，测试版，质量保证，生产)? [英] Multiple CDI configuration profiles (devel, beta, qa, production) in one war?

问题描述

具有使用Spring DI applicationContext.xml声明依赖项注入的经验，我现在尝试弄清楚如何使用Java EE6 CDI进行同样的操作.

Having experience with the Spring DI applicationContext.xml way of declaring Dependency Injection I now try to figure out how to do the same with Java EE6 CDI.

使用Spring，我可以将.jar附带几个配置文件，例如 unittest.xml，devel.xml，qa.xml，production.xml ，并使用命令行参数或环境变量将其激活.

With Spring, I could ship my .jar with several configuration profiles like unittest.xml, devel.xml, qa.xml, production.xml and activate them using command line parameters or environment variables.

有了CDI，我可以在 beans.xml 中使用@Alternative并在 web.xml 中使用属性，但是似乎无法为不同的环境提供多个bean.xml .

With CDI, I could use @Alternative in beans.xml and properties in of web.xml but there seems no way of shipping multiple beans.xml for different environments.

我不希望使用Maven配置文件/过滤器来生成我的应用程序的4-6版本，尽管我了解在某些情况下这将是更好的解决方案(例如，将现成的构建大战运送给客户-但我只使用我的内部发生战争，因此我们可以节省编译时间！)

I don't want to use Maven profiles/filters to produce 4-6 versions of my app although I understand that for some scenarios that would be the better solution (i.e. shipping ready build wars to customers - but I only use my wars internally so let's save compile time!)

最好，我还能够从文件系统中加载这些配置文件，以便系统管理员可以编辑它们，而不必重新构建应用程序.

Preferably, I would also be able to load those configuration files from the file system so that they could be edited by the sysadmins without having to re-build the app.

具有依赖项和属性的多个配置集的Java EE6方法是什么?

What is the Java EE6 way of having multiple configuration sets of dependencies and properties?

如果没有，那么截至2013年，推荐的替代方法是什么?使用Spring?接缝?帅哥我看到了提到Apache DeltaSpike的内容，但是从网页上看，它们似乎仍然是alpha判断.

If there is none, what are the recommended alternatives as of 2013? Using Spring? Seam? Guice? I saw mentionings of Apache DeltaSpike but they still seem alpha juding from the web page.

推荐答案

我将使用动态生成器，并使用Qualifier标识所需的环境

I'd use a dynamic producer, using a Qualifier to identify the desired environment

// The qualifier for the production/qa/unit test 
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD,
 ElementType.FIELD, ElementType.PARAMETER})
public @interface Stage {
   String value() default "production";
}

// The interface for the stage-dependant service
public interface Greeting{
    public String sayHello();
}

// The production service
@Stage("production")
public class ProductionGreeting implements Greeting{
    public String sayHello(){return "Hello customer"; }
}

// The QA service
@Stage("qa")
public class QAGreeting implements Greeting{
    public String sayHello(){return "Hello tester"; }
}

// The common code wich uses the service
@Stateless
public class Salutation{
   @Inject Greeting greeting; 
   public String sayHello(){ return greeting.sayHello(); };
}

// The dynamic producer
public class GreetingFactory{
    @Inject
    @Any
    Instance<Greeting> greetings;        

    public String getEnvironment(){
         return System.getProperty("deployenv");
    }

    @Produces
    public Greeting getGreeting(){
        Instance<Greeting> found=greetings.select(
           new StageQualifier(getEnvironment()));
        if (!found.isUnsatisfied() && !found.isAmbiguous()){
           return found.get();
        }
        throw new RuntimeException("Error ...");
    }

    public static class StageQualifier 
      extends AnnotationLiteral<Stage> 
      implements Stage {
       private String value;

       public StageQualifier(String value){
           this.value=value;
       }
       public String value() { return value; }
     }

}

因此，在此容器将所有可用的Greeting实现注入到GreetingFactory中，而该实现又根据系统属性'deployenv'决定将其用作@Producer.

So here the container injects all available Greeting implementations into GreetingFactory, which in turn serves as @Producer for the intended one, basing the decision on the system property 'deployenv'.

这篇关于在一次战争中有多个CDI配置配置文件(开发，测试版，质量保证，生产)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！