Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lift4: Support for Env Vars in configuration #2011

Open
dpp opened this issue Oct 19, 2023 · 5 comments
Open

Lift4: Support for Env Vars in configuration #2011

dpp opened this issue Oct 19, 2023 · 5 comments
Assignees
Labels
Lift4 Features/Changes for Lift 4

Comments

@dpp
Copy link
Member

dpp commented Oct 19, 2023

Lift's properties/configuration mechanism is based on named files. However, this means storing secrets (e.g., DB credentials, etc.) in files and potentially checking those files into source control systems. Yikes!!

The industry is moving to using Env Vars for configuration/secrets.

The proposal is to extend Lift's configuration system to support referencing Env Vars from configuration files (Rust has an env!(...) macro.

Thus if a line in a configuration file looks like:

foo.bar.baz=env!("VAR_NAME")

Lift's configuration system will read the env var and if the env var isn't define, the config system will throw an exception which will halt the Lift boot cycle.

@dpp dpp added the Lift4 Features/Changes for Lift 4 label Oct 19, 2023
@dpp dpp self-assigned this Oct 19, 2023
@andreak
Copy link
Member

andreak commented Oct 19, 2023

Many projects use Spring Boot and use its properties-loading mechanism.; It'd be nice if we could weave in some kind of interop with Spring Boot's properties.

@dpp
Copy link
Member Author

dpp commented Oct 19, 2023

Do you have a pointer to the Spring Boot properties package? Lemme see if I can do something with reflection so if it's there, it'll be used.

@andreak
Copy link
Member

andreak commented Oct 19, 2023

We inject Spring's org.springframework.core.env.Environment in Boot:

@Configurable
class Boot extends VisenaLoggable {

	@Resource(name = "origoDecoratorProvider")
	val decoratorProvider: ExecutionTaskDecoratorProvider = null
	@Resource(name = "liftSchedulerExecutor")
	val liftSchedulerExecutor: ExecutorService = null
	@Resource
	val springEnvironment: Environment = null

	def boot(): Unit = {

....
....
		LiftRules.ajaxRetryCount = Full(springEnvironment.getProperty("ajax.retryCount", classOf[Int]))

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/env/Environment.html

We use AspectJ's META-INF/aop.xml to configure how Spring should process "non-Spring managed classes":

<aspectj>
    <weaver options="-verbose -showWeaveInfo -XmessageHandlerClass:org.springframework.aop.aspectj.AspectJWeaverMessageHandler">
        <!--
        Only weave @Configurable stuff
        -->
        <include within="@org.springframework.beans.factory.annotation.Configurable no.officenet.origo..*"/>
        <include within="@org.springframework.beans.factory.annotation.Configurable com.visena..*"/>
		<include within="@org.springframework.beans.factory.annotation.Configurable bootstrap.liftweb.Boot"/>
	</weaver>

</aspectj>

@lvitaly
Copy link
Contributor

lvitaly commented Oct 19, 2023

Maybe it is worth supporting different config providers? For example, lightbend/config supports env variable out of the box.

@dpp
Copy link
Member Author

dpp commented Oct 20, 2023

I am suggesting a very simple extension to the existing Props mechanism that allows injection of environment variables into properties.

There's nothing in Lift that defaults to using the Props system... it's mostly stand-alone.

If there are other properties systems that are used with other systems, why not use those natively in the Lift app rather than trying to wrap Props (which is simple and dumb by design) around them?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Lift4 Features/Changes for Lift 4
Projects
None yet
Development

No branches or pull requests

3 participants