System environment variables in Jetty application

Question

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 ?

Rustler

Answer 1

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

External Configuration Properties with Jetty

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.

The props.war

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.

Example #1: Basic Command Line

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.

Example #2: Using start.ini

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

Example #3: Using start.d optional ini

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

Example #4: Using --include-jetty-dir optional config

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

Beaner

In this question #27158404 System.getProperties().contains("dbhost") - but neither adding dbhost="localhost" nor -Ddbhost="localhost" to the start.ini file works` So providing them to start.ini file also doesn't help as I have tried that from that comment. Can you edit your answer and include a small script on how to do what you suggested ? – Rustler

"Not supporting System.getenv() is not a Jetty thing, but a Java thing", I have looked in docs.oracle.com/javase/7/docs/api/java/lang/… and see no evidence that it is a "Java thing" that environment variables are not supported? Or do I misunderstand? If they're a good idea or not is not the same as if they're supported. It does seem to be a Jetty-specific thing that they're not supported. – Fogy

getenv() has been removed, then added, then removed again, then added again. Its got a long history of issues, and is still not stable, even today. – Beaner

@JoakimErdfelt Awesome post. Thank you for the detail guide and example. – Sean

@JoakimErdfelt I have the following use case. 3rd party server (I do not control the code) packaged as WAR, which consumes AWS STS regional endpoint using System.getenv docs.aws.amazon.com/sdkref/latest/guide/…. I need to pass AWS_STS_REGIONAL_ENDPOINTS environment variable to the process running the server. Is this not supported by Jetty as of 2022 ? It is what is keeping me with Tomcat. Is Jetty open to PR to support this use case ? – Manvil