We’re rewarding the question askers & reputations are being recalculated! Read more.
2 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

There are a couple options that present themselves in this case.

The first, is the properties file. Its location is somewhere and typically in the class path. Typically, you will see it coupled with the getResource family of calls.

Properties prop = new Properties();
prop.load(this.getClass().getResourceAsStream("stuff.properties");

Now, if you don't have the property file in the classpath, you could specify it in the system properties which can be accessed through the System class as described herehere.

With the invocation of: java -Dtest="true" -jar myApplication.jar the value can be extracted with: System.getProperty("test") and then used either to specify other resources or being a resource itself. While it isn't immediately visible with many application servers, its still there, somewhere. In Eclipse, you can easily see them by going to the run configuration and look at the VM arguments.

Similar to the system properties, there are the environment properties accessed through System.getenv. The rest of that set of documents is a good read - The Platform Enviroment. While it speaks mostly to Java SE, nearly everything in it is still applicable and an option for Java EE (I don't think you'll be looking at Java Web Start or Java applets).

Moving to the realm of the application server, we get to the names stored in the context of the application or server.

InitialContext ic = new InitialContext();
loc = (String) ic.lookup("java:com/env/app/location");

This value is actually stored in the server configuration itself. The documentation for tomcat. Note that each app server is different and you might get some ugliness in there. The only difference between the database from JNDI and a string is the type that it presents. One is a DataSource, the other is a String.

There are a couple options that present themselves in this case.

The first, is the properties file. Its location is somewhere and typically in the class path. Typically, you will see it coupled with the getResource family of calls.

Properties prop = new Properties();
prop.load(this.getClass().getResourceAsStream("stuff.properties");

Now, if you don't have the property file in the classpath, you could specify it in the system properties which can be accessed through the System class as described here.

With the invocation of: java -Dtest="true" -jar myApplication.jar the value can be extracted with: System.getProperty("test") and then used either to specify other resources or being a resource itself. While it isn't immediately visible with many application servers, its still there, somewhere. In Eclipse, you can easily see them by going to the run configuration and look at the VM arguments.

Similar to the system properties, there are the environment properties accessed through System.getenv. The rest of that set of documents is a good read - The Platform Enviroment. While it speaks mostly to Java SE, nearly everything in it is still applicable and an option for Java EE (I don't think you'll be looking at Java Web Start or Java applets).

Moving to the realm of the application server, we get to the names stored in the context of the application or server.

InitialContext ic = new InitialContext();
loc = (String) ic.lookup("java:com/env/app/location");

This value is actually stored in the server configuration itself. The documentation for tomcat. Note that each app server is different and you might get some ugliness in there. The only difference between the database from JNDI and a string is the type that it presents. One is a DataSource, the other is a String.

There are a couple options that present themselves in this case.

The first, is the properties file. Its location is somewhere and typically in the class path. Typically, you will see it coupled with the getResource family of calls.

Properties prop = new Properties();
prop.load(this.getClass().getResourceAsStream("stuff.properties");

Now, if you don't have the property file in the classpath, you could specify it in the system properties which can be accessed through the System class as described here.

With the invocation of: java -Dtest="true" -jar myApplication.jar the value can be extracted with: System.getProperty("test") and then used either to specify other resources or being a resource itself. While it isn't immediately visible with many application servers, its still there, somewhere. In Eclipse, you can easily see them by going to the run configuration and look at the VM arguments.

Similar to the system properties, there are the environment properties accessed through System.getenv. The rest of that set of documents is a good read - The Platform Enviroment. While it speaks mostly to Java SE, nearly everything in it is still applicable and an option for Java EE (I don't think you'll be looking at Java Web Start or Java applets).

Moving to the realm of the application server, we get to the names stored in the context of the application or server.

InitialContext ic = new InitialContext();
loc = (String) ic.lookup("java:com/env/app/location");

This value is actually stored in the server configuration itself. The documentation for tomcat. Note that each app server is different and you might get some ugliness in there. The only difference between the database from JNDI and a string is the type that it presents. One is a DataSource, the other is a String.

1
source | link

There are a couple options that present themselves in this case.

The first, is the properties file. Its location is somewhere and typically in the class path. Typically, you will see it coupled with the getResource family of calls.

Properties prop = new Properties();
prop.load(this.getClass().getResourceAsStream("stuff.properties");

Now, if you don't have the property file in the classpath, you could specify it in the system properties which can be accessed through the System class as described here.

With the invocation of: java -Dtest="true" -jar myApplication.jar the value can be extracted with: System.getProperty("test") and then used either to specify other resources or being a resource itself. While it isn't immediately visible with many application servers, its still there, somewhere. In Eclipse, you can easily see them by going to the run configuration and look at the VM arguments.

Similar to the system properties, there are the environment properties accessed through System.getenv. The rest of that set of documents is a good read - The Platform Enviroment. While it speaks mostly to Java SE, nearly everything in it is still applicable and an option for Java EE (I don't think you'll be looking at Java Web Start or Java applets).

Moving to the realm of the application server, we get to the names stored in the context of the application or server.

InitialContext ic = new InitialContext();
loc = (String) ic.lookup("java:com/env/app/location");

This value is actually stored in the server configuration itself. The documentation for tomcat. Note that each app server is different and you might get some ugliness in there. The only difference between the database from JNDI and a string is the type that it presents. One is a DataSource, the other is a String.