This is an open discussion about the ways in which a Lucee server, or Lucee application should be configured. We’re introducing some cool new things like system property config (http://lang.lucee.org/t/configure-lucee-via-system-properties/91) and I’d like to be able visualize all the ways config can be stored and used at run time to make sure our approach is holistic and well thought out.
Currently, I can think of three “logical” places that configuration exists
- Server level
- Web level
- Application level
Here are the possible ways I can think of that a developer can “interface” with configuration
- Browser-based server admin (persisted in lucee-server.xml)
- Browser-based web admin (persisted in lucee-web.xml)
- Application.cfc settings
- <cfadmin> tag (undocumented, must be run in context of web/server context you want to edit)
- (Java) System Properties - Right now appears to just be a bootstrap to point to the XML config files.
- OS Environment variables - Not actually implemented, but suggested in the system property post.
- Edit XML files directly and restart service
- CLI tooling (doesn’t exist, but I’ll discuss in another thread)
How do we feel about these options? The first line of config levels I think is pretty straight forward. The’s the second list that has some newcomers that could use some fleshing out. Like I mentioned, system props appear to only be useful currently as a shortcut for the settings found in web.xml that point to the luce-server.xml and lucee-web.xml files.
@micstriit hinted that it could be expanded to include most settings. What would that look like for complex, enumerated settings like cf mappings or data sources? Also, how would you specify properties that targeted settings for a specific web context, or even an application name within a given web context? Should all that be something that should be able to be specified in system properties or environment variables?
My big thing is I want consistency between all the ways that settings can be interacted with so everything that can be configured is equally available via each method.
Also, there’s been discussion on the format of Lucee’s persisted settings: XML. Should it stay XML or transition to something different? Should editing of these files be encouraged, or should they be treated as an undocumented internal concern that can change at any time in any release? If the latter, should there be some supported method (either static like JSON, or programmatic like Application.cfc) that all the settings for a server or web context can be stored in a portable fashion and even shipped as part of the app’s source code? (kind of like php.ini)