Jetty.project: <property> config tag can't access property values in WebAppContext

[jscheible-transporeon]

After passing a key-value pair at startup time (java -jar start.jar foo=bar --list-config) referencing the property in jetty.xml with a <reference> tag works (instance of org.eclipse.jetty.server.Server) but neither in web-app-context.xml nor in jetty-env.xml of the web application (both are instances of org.eclipse.jetty.webapp.WebAppContext).

I tested it with JNDI EnvEntry tags (this one is from jetty.xml):

<New class="org.eclipse.jetty.plus.jndi.EnvEntry">
    <Arg>env/foo</Arg> <!-- resp. env/context/foo and env/jetty-env/foo for web-app-context.xml and jetty-env.xml -->
    <Arg><Property name="foo" default="foo-not-found"/></Arg>
</New>

Only for env/foo the value is foo whilst for env/context/foo and env/jetty-env/foo it is foo-not-found.

[joakime]

startup properties only exist for purposes of startup.

If you want properties to show up during deployment of webapps, (which isn't part of startup btw), then you can use the optional org.eclipse.jetty.deploy.PropertiesConfigurationManager setup in the DeploymentManager. These properties will available for use in your jetty-env.xml and ${jetty.base}/webapps/<appname>.xml deployables.

See example in your ${jetty.home}/etc/jetty-deploy.xml

Optionally, you can use system properties on startup, and those are always available for the lifetime of the JVM.
You would switch from using <Property> to <SystemProperty>

[jscheible-transporeon]

Thanks a lot for your answer again.

Using system properties isn’t an option because I would like to pass for example a database password.

I followed your advice and gave PropertiesConfigurationManager in jetty-deploy.xml a try.
Now the property value is accessible via <Property> in web-app-context.xml but still not in the jetty-env.xml of the WAR.
How to make a property from an external property file accessible in the jetty-env.xml?

The background is that unfortunately I need to use jetty-env.xml because the we want full self-contained WARs. That means that JNDI entries as well JARs for JNDI resources like jdbc driver must be under full control of the WAR owner/creator. Only environment specific values (like the mentioned database password) must be override from the outside (the property file).

How about adding some hints about scoping of properties to the documentation of <Property> (or perhaps to the more specific ones like 'jetty-env.xml')?

[janbartel]

So I think there's a couple of problems here. Firstly, when the jetty-env.xml file is being interpreted, it has no knowledge of the DeploymentManager and the PropertiesConfigurationManager, so it will not be able to access any custom properties in the same way that the webapp context xml file can. Not sure what we can do to make them visible, maybe we could put the PropertiesConfigurationManager into a context attribute at a well-known address so we can access its properties outside of the DeploymentManager - @joakime any suggestions?

Secondly, I see that when the jetty-env.xml file is being interpreted, it doesn't even set up the standard properties ("Server", "jetty.home", "jetty.base" etc). I'll fix that.

[janbartel]

PR #2806 makes standard jetty properties available for reference in jetty-env.xml file. Still need ability to reference custom properties supplied with the deployer.

[joakime]

@janbartel the PropertiesConfigurationManager might need to push a Map<String,Object> to a well known location on the server, but then what would we do when there are 2 deployment managers with different configurations? How do we associate the webapp to the correct properties (and/or PropertiesConfigurationManager)?

[janbartel]

@joakime I'm not seeing the problem: surely one context is only ever deployed by a single DeploymentManager? So the context attribute will contain the properties relevant to the DeploymentManager that deployed it?

[stale[bot]]

This issue has been automatically marked as stale because it has been a full year without activit. It will be closed if no further activity occurs. Thank you for your contributions.

[joakime]

This has been fixed in commit 23bf2504fe44cccf733aafe78505df2e114d2fc7