I want to write multiple function inside our app so instead of putting config in application.yml I use MICRONAUT_FUNCTION_NAME environment variable in AWS lambda but I keep receiving the error
No function found for name: xxx: java.lang.IllegalStateException
java.lang.IllegalStateException: No function found for name: xxx
at io.micronaut.function.executor.AbstractExecutor.lambda$resolveFunction$0(AbstractExecutor.java:60)
at java.util.Optional.orElseThrow(Optional.java:290)
at io.micronaut.function.executor.AbstractExecutor.resolveFunction(AbstractExecutor.java:60)
at io.micronaut.function.executor.StreamFunctionExecutor.execute(StreamFunctionExecutor.java:89)
at io.micronaut.function.aws.MicronautRequestStreamHandler.handleRequest(MicronautRequestStreamHandler.java:54)
Do anyone know what did I miss or it's not possible for multiple functions?
You can use io.micronaut:micronaut-function-aws:1.4.0 with micronaut version 1.3.3.
This happens because I use Micronaut version 1.3.3. If I downgrade to 1.2.11, it works perfectly.
Related
I have two services, which both use the same interface and one is injected in the other.
With this configuration in the service.yaml everything worked well:
# fix autowiring for 2 services using the same interface
App\Domain\ListService: ~
App\Domain\SapService\SapListService: ~
App\Domain\ListService $sapListService: '#App\Domain\SapService\SapListService'
App\Domain\ListServiceInterface: '#App\Domain\ListService'
following the official documentation found here.
Now one of my services needs the information in which environment the class is currently running.
In a simple service configuration I would write it like this:
App\Service\FooService:
arguments:
$env: '%env(APP_ENV)%'
But how do I add the environment information in my more complex situation?
I tried this:
App\Domain\ListService: ~
App\Domain\SapService\SapListService: ~
App\Domain\ListService $sapListService: '#App\Domain\SapService\SapListService'
arguments:
$env: '%env(APP_ENV)%'
App\Domain\ListServiceInterface: '#App\Domain\ListService'
which throws this error:
The file "/var/www/src/../config/services.yaml" does not contain valid YAML: Unable to parse at line 52 (near " arguments:").
What is the proper formatting to parse the environment information into my service?
I tried manual wiring like this:
public function __construct(
ListServiceInterface $sapListService,
#[Autowire('%env(APP_ENV)%')]
string $env
) {
$this->sapListService = $sapListService;
$this->env = $env;
}
which gives me the error:
In DefinitionErrorExceptionPass.php line 54:
Cannot autowire service "App\Domain\ListService": argument "$env" of method "__construct()" is type-hinted "string", you should configure its
value explicitly.
Looks like the Autowire annotation is only available with symfony 6
You should use the namespace in the redis config to separate the different environments and not use the APP_ENV var to create the keys to store.
I guess the best solution is to prefix the cache key with the environment via the cache configuration in the cache.yaml file.
The solution is described here
I am using test container with Janusgraph, but I need to use ConfiguredGraphFactory in my test. How to enable it in test container? This is how I am starting the test container:
GenericContainer<JanusGraph> janus = new JanusGraph()
.withNetwork(network)
.withExposedPorts(JANUS_PORT)
.waitingFor(Wait.forListeningPort())
.withStartupTimeout(Duration.ofMinutes(5))
.withEnv("janusgraph.storage.backend", "cql")
.withEnv("janusgraph.storage.hostname", storageName)
.withEnv("janusgraph.index.search.backend", "elasticsearch")
.withEnv("janusgraph.index.search.hostname", indexName)
.withEnv("janusgraph.schema.default", "tp3");
I was trying to add .withEnv("janusgraph.graph.graphname"."org.janusgraph.core.ConfiguredGraphFactory") but it doesn't work (image name: janusgraph/janusgraph:0.5.3).
The example yaml and properties files for trying ConfiguredGraphFactory can be found at:
conf/gremlin-server/gremlin-server-configuration.yaml
conf/janusgraph-cql-configurationgraph.properties
It is described in the janusgraph-docker project that you can define gremlin.* and janusgraph.* environment variables in your Dockerfile to override the default configs. Your approach with GenericContainer.withEnv() should be fine too.
From looking at this JanusGraph PR, I think this approach should work:
.withEnv("gremlin.graph"."org.janusgraph.core.ConfiguredGraphFactory")
However, I have no experience with JanusGraph and I think this is not a Testcontainers-specific question. This means you can conceptually configure it for Testcontainers the same way to would configure it for a Docker container with the Docker CLI.
I am trying to set the serverless service name from the env file. Before deploying serverless, I have set the value of ECR_NAME as
export ECR_NAME=$(echo $CI_ENVIRONMENT_SLUG | awk -v srch="-" -v repl="" '{ gsub(srch,repl,$0); print $0 }')
Then I have written it as below in the serverless.yml.
service: ${env:CI_PROJECT_NAME}-${env:ECR_NAME}
useDotenv: true
configValidationMode: error
variablesResolutionMode: 20210326
Getting the below error:
Error:
Cannot resolve serverless.yml: "service" property is not accessible (configured behind variables which cannot be resolved at this stage)
Installed version
Framework Core: 3.14.0
Plugin: 6.2.1
SDK: 4.3.2
See Issue #9313 on GitHub:
https://github.com/serverless/serverless/issues/9813
Problem:
The latest version of the serverless framework is no longer working
for AWS Lambda deployments and is throwing the following error:
Cannot resolve serverless.yml: “provider.stage” property is not accessible (configured behind variables which cannot be resolved at this stage)
Discussion:
with the new resolver, such definition is not supported. In general,
it is discouraged to configure stage behind env variables for example,
as at the point where stage is going to be resolved, not whole env
might be available (e.g. loading env vars from .env.{stage} needs to
resolve stage first in order to properly load variables from file),
which might introduce bugs that are hard to debug. Also, the
provider.stage serves more as a "default" stage and --stage flag via
CLI is the preferred way of setting it.
...
In your configuration file you explicitly opt-in to use new resolver
via variablesResolutionMode: 20210326 variable.
We are not discouraging the use of env variables - quite the contrary,
we've been promoting them as a replacement for custom CLI options for
example and it is generally a great practice to use them. As for env
source for stage specifically, this has been introduced as a fix, as
stage should be already resolved before we attempt env variables
resolution, as loading .env files can depend on stage property.
#medikoo I know we've talked about it today, do you think it could be
safe to resolve stage from env source in specific circumstances (e.g.
when dotenv is not used)?
See also:
https://www.serverless.com/framework/docs/deprecations/#new-variables-resolver
https://www.serverless.com/framework/docs/providers/aws/guide/variables/
I want to setting the default logging level to error on springboot
enter image description here
But the console still has the dubug and info output. It seems that logging.level.root=error doesn't work.
Be carefull if you are using Spring Boot Devtools, the properties defined in $HOME/.config/spring-boot folder will override all other properties as specified in Spring Boot documentation : https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html
I found a environment variable named debug,even though its value is a string not true,which caused the problem.Actually,I tried to remove the variable before,but I didn't restart the eclipse.Now,I remove the varibale named DEBUG and restart the eclipse,and it success.
Is it possible to set SonarQube's web context path using a command line parameter?
Usually you would set property sonar.web.context=/sonarqube (or similar) in sonar.properties file. But I'm using Docker and would like to avoid editing sonar.properties.
With Docker Compose I got the following which is working like a charm for other command line parameters:
services:
sonarqube:
image: sonarqube:5.4
[...]
entrypoint:
- ./bin/run.sh
- -Dsonar.log.level=INFO
- -Dsonar.web.context=/sonarqube
But it seems to ignore -Dsonar.web.context=/sonarqube :( Is there a way to pass SonarQube a different context path?
Additional info: This is corresponding run.sh file.
With SonarQube 5.4 this is bound to fail: sonar.web.context was dropped in SonarQube 5.4 (SONAR-7122, suggested alternative being to use a sub-domain) and re-introduced in 5.5 (SONAR-7494) following community feedback.
They added the context back in 5.5 RC1
https://jira.sonarsource.com/browse/SONAR-7494