Configure Lucee via System properties

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

Yeah, good point.

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?).

https://luceeserver.atlassian.net/browse/LDEV-1746