Lucee 5 allows to configure a few things with help of system properties
https://bitbucket.org/lucee/lucee/wiki/System.properties%20(Work%20in%20progress)
System properties
System properties supported by Lucee:
lucee.base.dir
(base directory for the engine)
lucee.server.dir
(server context, same as init param lucee-server-directory)
lucee.web.dir
(web context, same as init param lucee-web-directory)
lucee.controller.interval
(number of milliseconds between controller calls, 0 to disable controller [useful for benchmark testing etc])
we should extend that to allow most settings to be made this way, that makes it easier to use Lucee in servlet free enviroments
Micha
2 Likes
Sounds good. But why not Environemnt variables too? I currently hold quite a few global parameters in ENV variables, and it is pretty convenient.
1 Like
What does this property control:
lucee.controller.interval (number of milliseconds between controller calls, 0 to disable controller [useful for benchmark testing etc])
Andrew Penhorwood
We’ve been thinking about this a lot too. Syntax could be interesting - i.e. how might you define a mapping through either system properties and/or environment variables…
lucee.mappings='{ "/preside" : { "physical":"/opt/preside/preside-10.0.0.394/" } }'
Tricky.
Another option that crossed my mind is having a configurable “additional” context settings file that uses the same format as the standard lucee-web.xml.cfm
file. In here, you could supply additional mappings + any other settings you’d like. This could be defaulted to something like: /{context-root}/lucee-web.xml
. So:
<?xml version="1.0" encoding="UTF-8"?>
<cfLuceeConfiguration>
<mappings>
<mapping physical="{system.property.or.env.variable.value}" primary="physical" trusted="true" virtual="/my-mapping" />
</mappings>
<!-- etc. -->
</cfLuceeConfiguration>
You should, as in the example above, be able to use system properties and environment variables within the configuration. It may also be worth exploring non xml alternatives.
1 Like
We need to check if there is a limitation in the length of this properties …
Yes, also that syntax would be pretty verbose and potentially very messy. Perhaps better in this circumstance to use a configuration file as we currently do and be able to have the config parser be able to use environment variables and system properties when reading {code}
“tags” (or does it do this already?).