How to configure system environment variables inside one Jetty application?
e.g. For database connection details, putting it in file and checking it into cvs is bad idea. For that reason using system environment is one way to go. While the system environment variables are defined in /etc/environments file or .bashrc/.zshrc file , in Jetty application, doing System.getenv("variable_name") won't give anything. It will result in null.
I have read this question: Configuring a Jetty application with env variables which concludes that which tells that Jetty doesn't support System.getenv() and not even in start.ini file.
And jetty and etc environment on ubuntu 12.10 which says In the jetty.sh script you can source the /etc/environment file and they will be present. which I tried and didn't get the values as expected meaning it gave me only null.
If I can't use the default System.getenv() or in any .ini file then how to specify credentials such as Database connection etc ?
Not supporting System.getenv() is not a Jetty thing, but a Java thing.
There are ton of restrictions around System.getenv() and your environment, making it nearly useless in all but the most naive and basic test case. (eg: multiline values are not supported. multiline entries can break parsing. keys without values are not supported. keys without values can often merge with next key during parsing. entries with non US-ASCII characters are not supported. entries with control characters are not supported.)
The common technique when using System Environment variables with Java programs is to use the shell specific techniques to obtain the values and inject them either on the command line, or into a ini file format for Jetty to then use.
Depending on your technique, these values would either show up as Jetty properties, or as Java System Properties.
Just created a project to demonstrate 4 ways to accomplish this at
https://github.com/jetty-project/jetty-external-config
Demonstration of how to configure simple properties that can be accessed by Servlets within Jetty.
This demonstration shows 4 different ways to configure a property at runtime, that can then be read by the Servlet running within Jetty.
This is a simple war file with a single HttpServlet and a WEB-INF/web.xml
[jetty-external-config]$ jar -tvf target/props.war
0 Mon Feb 23 09:02:14 MST 2015 META-INF/
131 Mon Feb 23 09:02:14 MST 2015 META-INF/MANIFEST.MF
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/eclipse/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/eclipse/demo/
2188 Mon Feb 23 09:02:12 MST 2015 WEB-INF/classes/org/eclipse/demo/PropsServlet.class
572 Mon Feb 23 08:45:22 MST 2015 WEB-INF/web.xml
See PropsServlet.java for details of behavior.
Just compile the top level and the war file will be built and placed in all of the demo jetty.base locations for this project.
The /base-command-line project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp. no extra configuration is done by the on-disk configuration.
If you start it up like so ...
[base-command-line]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:15:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:15:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
2015-02-23 09:15:46.235:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/joakim/code/stackoverflow/jetty-external-config/base-command-line/webapps/] at interval 1
2015-02-23 09:15:46.325:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /props, did not find org.eclipse.jetty.jsp.JettyJspServlet
2015-02-23 09:15:46.343:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext@6e7f61a3{/props,file:/tmp/jetty-0.0.0.0-9090-props.war-_props-any-27537844855769703.dir/webapp/,AVAILABLE}{/props.war}
2015-02-23 09:15:46.353:INFO:oejs.ServerConnector:main: Started ServerConnector@67cd35c5{HTTP/1.1}{0.0.0.0:9090}
2015-02-23 09:15:46.353:INFO:oejs.Server:main: Started @555ms
you'll see that it has started up and deployed to the /props context path.
From here you can test for properties in the servlet via tooling like wget or curl.
Example:
$ curl http://localhost:9090/props/props
[java.runtime.name] = Java(TM) SE Runtime Environment
[sun.boot.library.path] = /home/joakim/java/jvm/jdk-7u75-x64/jre/lib/amd64
[java.vm.version] = 24.75-b04
[java.vm.vendor] = Oracle Corporation
[java.vendor.url] = http://java.oracle.com/
...
[file.separator] = /
[java.vendor.url.bug] = http://bugreport.sun.com/bugreport/
[sun.io.unicode.encoding] = UnicodeLittle
[sun.cpu.endian] = little
[sun.desktop] = gnome
[sun.cpu.isalist] =
You can even request a specific property ..
$ curl http://localhost:9090/props/props/user.timezone
[user.timezone] = America/Phoenix
Lets stop the server and run it with a system property of our choice.
Notice the -Dfoo=bar ?
[base-command-line]$ java -Dfoo=bar -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:15:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:15:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
2015-02-23 09:15:46.235:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/joakim/code/stackoverflow/jetty-external-config/base-command-line/webapps/] at interval 1
2015-02-23 09:15:46.325:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /props, did not find org.eclipse.jetty.jsp.JettyJspServlet
2015-02-23 09:15:46.343:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext@6e7f61a3{/props,file:/tmp/jetty-0.0.0.0-9090-props.war-_props-any-27537844855769703.dir/webapp/,AVAILABLE}{/props.war}
2015-02-23 09:15:46.353:INFO:oejs.ServerConnector:main: Started ServerConnector@67cd35c5{HTTP/1.1}{0.0.0.0:9090}
2015-02-23 09:15:46.353:INFO:oejs.Server:main: Started @555ms
and look for it via curl ...
$ curl http://localhost:9090/props/props/foo
[foo] = bar
That demonstrates access of a property that was specified via the command line, now lets look at the other choices.
The /base-startini project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp.
This start.ini also contains a foo.ish property.
Lets start up Jetty and try our props servlet access again ...
[base-startini]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:16:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:16:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
and request it via curl ...
$ curl http://localhost:9090/props/props/foo.ish
[foo.ish] = bar
The /base-startd project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp.
This start.ini also contains no extra properties that we are interested in.
The start.d/myconf.ini contains a property called foo.d that we are interested in.
Lets start up Jetty and try our props servlet access again ...
[base-startd]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:19:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:19:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
and request it via curl ...
$ curl http://localhost:9090/props/props/foo.d
[foo.d] = over here
The /base-jettyinclude project contains a new start.ini which starts jetty on port 9090, and deploys the webapp.
This start.ini also contains no extra properties that we are interested in.
However, the start.ini uses the --include-jetty-dir=../jettydir optional configuration that points to an entirely new interrim jetty.base configuration source.
The ../jettydir/start.ini contains a property called foo.jetty.dir that we are interested in.
Lets start up Jetty and try our props servlet access again ...
[base-jettyinclude]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:24:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:24:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
and request it via curl ...
$ curl http://localhost:9090/props/props/foo.jetty.dir
[foo.jetty.dir] = more of the same