Use Stage to activate a specific Spring profile

[mattcorey]

If the lambda is running under a specific 'stage', the component should use this to activate a Spring profile that may be packaged with the function. This will allow the user to control different configurations (data source, output queue, etc) based on the stage it's running as (test, prod, etc)

[sapessi]

thanks Matt, will look into this ASAP.

[mattcorey]

I've done this before, and may be able to get to it in the next few days. If you agree with the premise I've proposed, I can implement this.

[mattcorey]

I have a working version of this that just needs some cleanup - I should be able to finish it tonight or tomorrow

[sapessi]

I think it's an interesting idea. Although we often recommend you deploy completely separate API/Lambda functions for each environment - ie they may have the same stage and the API id/function arn distinguishes between a prod and dev one. See the pipeline example here: https://aws.amazon.com/blogs/compute/continuous-deployment-for-serverless-applications/

[mattcorey]

This looks really similar to what we're doing - we use the Serverless Framework for our deployments, which offers a similar way to model a serverless app in a single place. Our resources are independent by stage, using a key in the name of the resources to determine where it should be used. Any other configuration is managed in the Spring profiles, such as feature switches, etc. This allows me to disable a feature switch in the 'production' profile, while enabling it everywhere else, for example.

[sapessi]

How do you normally activate a profile? Assume you use the @Profile annotation and then call the setActiveProfile method on the application context? If that's the case, I will add a setActiveProfile method to the SpringLambdaContainerHandler that changes the profile of the current application context

[mattcorey]

I use both the @Profile annotation to setup specific bean/resource settings, and the application-.properties pattern standardized in SpringBoot, and I use the 'setActiveProfile' to set it. I have a working example in my forked repository: https://github.com/mattcorey/aws-serverless-java-container/tree/profile-support

One gotcha I found when putting tests together for this -- In order to test in various profile configurations, I needed to effectively reset the Spring context, and I found that the static variable AwsProxyServletContext.instance was preventing me from doing this. My test cases SpringProfileTest would pass individually, but fail when I ran them both at once, or when I ran the entire test suite.

I addressed this in this branch temporarily by creating a method to clear this 'cache', which I then hit in my '@before' method, but this is awkward at best, and probably not scalable. I wanted to get your take on this before creating a pull request.

[sapessi]

I took a look at your branch. I'm not 100% sure I'd want to use the API Gateway stage automatically.

I think we should add the getStage method to the AwsProxyServletContext like you did, but then I'd let you set the profile directly on the application context before you pass it to the library. What I'm getting at is that I'm not sure the library should be involved in setting the profile.

I can also see us adding a method to the SpringLambdaContainerHandler to get the current application context. How do you feel about this solution?

[mattcorey]

I see what you're getting at - to this point, I'm designing my apps to be deployed Into AWS Lambda first, but it won't necessarily be the case.

I'm not sold on asking the developer to explicitly get the stage, and then activate the profile based on it, because I don't think developers think about profiles as an API option, but rather as a runtime switch. In addition to exposing the ApplicationContext, what if we added an 'activateSpringProfile' method to the SpringLambdaContainerHandler when it's created to handle it? Overkill?

[sapessi]

I like the idea of adding an activateSpringProfile method to the container handler. This way the profile name could come from both environment variables in Lambda or stages in API Gateway. I think it's more flexible. Do you want to make the changes to your branch and send a pull request or want me to add the method and copy your tests?

[mattcorey]

I took a whack at it -- take a look on the new branch: https://github.com/mattcorey/aws-serverless-java-container/tree/simplified-profile-support

[sapessi]

Looks good. Want to send the pull request?

[mattcorey]

Done