Environmental-specific properties at JBOSS AS7

Question

We have 4 servers that run JBOSS AS7:

• Dev
• test
• according to
• prod

Each jboss launches a simple webapp. This webapp will use spring and requires some properties to be set as follows:

webservice.endpoint=interface.url.com webservice.port=7676 

Properties will vary for each environment. The way we handle this at this point is as follows:

I have a JAR file with one file in it, config.properties. This properties file contains all my properties. I turn this jar into a global jboss module and configure it in my domain.xml (or standalone.xml ) to be included. This works because spring can access properties when creating beans.

However, it seems too complicated to turn properties into a jar into a module. I thought I should use system properties for this? My question is: is this a good place to host all environment-specific, application-specific properties? Will they be loaded into the JVM so that everyone can access them at will (especially Spring, which uses the ${myProperty} notation to access properties). Also, when I add properties using the console in my browser, have they been saved? I do not see them in domain.xml or host.xml .

Answer 1

if you use the JAR solution: - use a unique classifier for each environment. You will have x property files: dev_config.properties/test_config.properties, etc.

that way you can simply set a unique JAVA_OPTS that sets up the environment in which you are located. then you will get the correct properties file:

using: System.getenv("ENV") or System.getProperty("ENV")

 if ("DEV".Equals(System.getenv("ENV")) here you load ==> the dev_config.properties 

to load properties into a JAR is very simple with this maven plugin.

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <executions> <execution> <id>packaging-deployment_manifests_bundle</id> <phase>package</phase> <goals> <goal>attached</goal> </goals> <configuration> <descriptors> <descriptor>descriptors/deployment_manifests_bundle.xml</descriptor> </descriptors> </configuration> </execution> </executions> </plugin> 

if you go to environment_variables : I have never tried this solution in my projects, I always went with the solution of the properties file. but if you only have a few variables to set, it can be even faster ... you can access these variables with:

 import java.util.Map; public class EnvMap { public static void main (String[] args) { Map<String, String> env = System.getenv(); for (String envName : env.keySet()) { System.out.format("%s=%s%n", envName, env.get(envName)); } } } 

Adding data to environment variables may be OK if it is not sensitive, such as passwords, etc. It is easier IMO to obfuscate data in the properties file. Therefore, if safety is at stake, this must be considered.

Answer 2

At my company, we use to store environment-dependent properties in a database. This means that you have a database for each environment. Not sure if your application has a database to store them.

Another solution would be to use a system property, which you either define differently on each server, or change the runtime at server startup:

• specify in your standalone.xml file with default , which will be used if my.cmd-line-descriptor not specified

   <system-properties> <property name="my-specific-value" value="${my.cmd-line-descriptor:default}"/> ... </system-properties> 

• change it if necessary when launching appserver:

   java ... -Dmy.cmd-line-descriptor=another-value 

For your additional question, I suggest you look at the changes made from the console in the tmp/vfs your applications.

Answer 3

If you use Maven in a project, you can set these properties in an environment in different profiles:

 <profiles> <profile> <id>dev</id> <properties> <webservice.endpoint>interface.url.com</webservice.endpoint> <webservice.port>7676</webservice.port> </properties> </profile> <profile> <id>test</id> <properties> <webservice.endpoint>test url</webservice.endpoint> <webservice.port>whatever port</webservice.port> </properties> </profile> </profiles> 

Then, when you compile the project, you must specify the environment that you compile it in order to use the properties of this profile in the -P parameter:

 maven clean install -P dev 

You can then access these properties using Spring.

Answer 4

I do not see them in domain.xml or host.xml

They are at the top level in <server> for standalone or <domain> for such a domain

 <server xmlns="urn:jboss:domain:1.7"> ... <system-properties> <property name="myapp.env" value="dev"/> </system-properties> ... </server> 

then Spring can see this as ${myapp.env} or any other code as system code.

They can be installed from the JBoss Admin Console, as well as on the “Configuration” tab at the very bottom of “System Properties” - this is actually the contents of this <system-properties> in domain.xml

They can also be used inside domain.xml. As an example, if you have myapp.properties files in different directories based on your environment, you can do this as:

 <server xmlns="urn:jboss:domain:1.7"> ... <system-properties> <property name="myapp.env" value="dev"/> <property name="myapp.config.file" value="${myapp.env}/myapp.properties"/> </system-properties> ... 

Thus, the path to the file will be dev/myapp.properties , and Spring will see it as $ {myapp.config.file}, after which it can load the properties.

PS. Also, as I recall, certain system properties can be set in the module definition or even in the application deployment descriptor jboss-deployment-structure.xml - not sure about the latter ... BTW this does not apply to your question about differentiation by environment.

SFC. About how .properties is stored on the file system. Storing them in a JAR file is a bad idea. it needs to be rebuilt and deployed every time a property is changed.

.properties files to avoid this. Therefore, they must be out of deployment.

Therefore, it depends on the organization’s network policy.

From time to time it was an NFS directory with different file names such as dev_myapp.properties, test_myapp.properties, etc.

At other times, it was one NFS directory with subdirectories - dev, test, etc. with the same file name in each.

NFS is not allowed in my current organization. Each slave instance in the cluster has its own clone file in the same place, i.e. config/myapp.properties . therefore, there is only one system property, defined as the path to this file. Each environment has its own version of the file.

Good luck