wildfly: lecture des propriétés de configuration de l'annuaire

Voici un exemple complet d'utilisation de seulement CDI, prises à partir de ce site.

1. Créer et remplir un fichier de propriétés à l'intérieur de la WildFly dossier de configuration

   $ echo 'docs.dir=/var/documents' >> .standalone/configuration/application.properties

2. Ajouter un système de propriété à la WildFly fichier de configuration.

   $ ./bin/jboss-cli.sh --connect
   [standalone@localhost:9990 /] /system-property=application.properties:add(value=${jboss.server.config.dir}/application.properties)

Cela va ajouter les lignes suivantes à votre fichier de configuration du serveur (standalone.xml ou domain.xml):

<system-properties>
    <property name="application.properties" value="${jboss.server.config.dir}/application.properties"/>
</system-properties>

1. Créer le singleton bean de session que les charges et les magasins de l'application à l'échelle des propriétés

   import java.io.File;
   import java.io.FileInputStream;
   import java.io.IOException;
   import java.util.HashMap;
   import java.util.Map;
   import java.util.Properties;
   
   import javax.annotation.PostConstruct;
   import javax.ejb.Singleton;
   
   @Singleton
   public class PropertyFileResolver {
   
       private Logger logger = Logger.getLogger(PropertyFileResolver.class);
       private String properties = new HashMap<>();
   
       @PostConstruct
       private void init() throws IOException {
   
           //matches the property name as defined in the system-properties element in WildFly
           String propertyFile = System.getProperty("application.properties");
           File file = new File(propertyFile);
           Properties properties = new Properties();
   
           try {
               properties.load(new FileInputStream(file));
           } catch (IOException e) {
               logger.error("Unable to load properties file", e);
           }
   
           HashMap hashMap = new HashMap<>(properties);
           this.properties.putAll(hashMap);
       }
   
       public String getProperty(String key) {
           return properties.get(key);
       }
   }

2. Créer le CDI de qualification. Nous allons utiliser cette annotation sur la Java des variables que nous souhaitons insuffler dans.

   import java.lang.annotation.ElementType;
   import java.lang.annotation.Retention;
   import java.lang.annotation.RetentionPolicy;
   import java.lang.annotation.Target;
   
   import javax.inject.Qualifier;
   
   @Qualifier
   @Retention(RetentionPolicy.RUNTIME)
   @Target({ ElementType.METHOD, ElementType.FIELD, ElementType.CONSTRUCTOR })
   public @interface ApplicationProperty {
   
       //no default meaning a value is mandatory
       @Nonbinding
       String name();
   }

3. Créer le producteur de la méthode, ce qui crée l'objet à être injecté

   import javax.enterprise.inject.Produces;
   import javax.enterprise.inject.spi.InjectionPoint;
   import javax.inject.Inject;
   
   public class ApplicaitonPropertyProducer {
   
       @Inject
       private PropertyFileResolver fileResolver;
   
       @Produces
       @ApplicationProperty(name = "")
       public String getPropertyAsString(InjectionPoint injectionPoint) {
   
           String propertyName = injectionPoint.getAnnotated().getAnnotation(ApplicationProperty.class).name();
           String value = fileResolver.getProperty(propertyName);
   
           if (value == null || propertyName.trim().length() == 0) {
               throw new IllegalArgumentException("No property found with name " + value);
           }
           return value;
       }
   
       @Produces
       @ApplicationProperty(name="")
       public Integer getPropertyAsInteger(InjectionPoint injectionPoint) {
   
           String value = getPropertyAsString(injectionPoint);
           return value == null ? null : Integer.valueOf(value);
       }
   }

4. Enfin injecter de la propriété dans l'un de vos CDI haricots

   import javax.ejb.Stateless;
   import javax.inject.Inject;
   
   @Stateless
   public class MySimpleEJB {
   
       @Inject
       @ApplicationProperty(name = "docs.dir")
       private String myProperty;
   
       public String getProperty() {
           return myProperty;
       }
   }

OriginalL'auteur Chris Ritchie

Il semble que le problème que vous essayez de résoudre, c'est de gérer différents (mais probablement similaire), les fichiers de configuration pour l'exécution de votre application dans des environnements différents (ie, la Production, l'assurance qualité, ou même de différents clients). Si c'est le cas, jetez un oeil à Jfig http://jfig.sourceforge.net/ . Il serait élimine le besoin pour le stockage des fichiers de propriétés à l'extérieur de votre classpath (mais vous avez encore le pourrait).

Ce qui est nécessaire est une approche hiérarchique des fichiers de configuration. Les quatre-vingt-dix pour cent des valeurs de configuration qui ne changent pas, peut être maintenu dans un fichier de base. Les dix pour cent (ou moins) peuvent être maintenus dans leur propre fichier de configuration. Au moment de l'exécution, les fichiers sont superposées les unes aux autres de manière à fournir un flexible, maniable de configuration. Par exemple, dans un environnement de développement myhost.config.xml combine avec dev.config.xml et base.config.xml à former ma configuration unique.

Chaque fichier de configuration peut alors être maintenue dans le contrôle de version comme ils ont des noms uniques. Seuls les fichiers de base doivent être modifiées lorsque les valeurs de base de changement, et il est facile de voir la différence entre les versions. Un autre avantage majeur est que les modifications apportées à la base du fichier de configuration seront testés de manière exhaustive avant le déploiement.

OriginalL'auteur Sr Bruno