I have the following property in my application.properties
// application.properties
LOCAL.JWT_PUBLIC_KEY=${JWT_PUBLIC_KEY:KEY_JWT}
And I'm injecting that property using the microprofile config anotation ConfigProperty
// OnPremiseSecrets.java
public JwtConfig(#ConfigProperty(name = "LOCAL.JWT_PUBLIC_KEY") String jwtPublicKey)
it works perfectly while running the program in JVM with a compiled jar quarkusDev
but it doesn't work in a native graalvm compilation, in the logs it return KEY_JWT as jwtPublicKey value which is the default.
I tried reading enviernment variables directry using
System.getenv
and it returns the right value, the environment variable is configured
Related
Developed the integration tests using Test container. Have few fields as environment variables(Eg: passing it as quarkus.datasource.username=${SER_DB_USERNAME:postgres}) in application.properties file.
When setting environment field through test container
GenericContainer<?> someService = new GenericContainer<>(img)
.withEnv("SER_DB_USERNAME", DataLayer.DB_USERNAME)
This value is being successfully taken with test containers but
For the below environment variable,
app.security.enabled=${SER_SEC_ENABLE:true} defined in application.properties file
#IfBuildProperty(name = "app.security.enabled", stringValue = "true")
the environment variable is setting through cmd prompt using -DSER_SEC_ENABLED=true, but when trying to pass the same value in test containers, it's always null.
GenericContainer<?> someService = new GenericContainer<>(img)
.withEnv("SER_SEC_ENABLE", "true")
Without having more context of the project, I can at least observe, that app.security.enabled is a build property rather than a runtime property, so it might be evaluated at build time already. If you start the container with an already built image/application, it is very likely, that the environment variable has no effect.
Furthermore, setting a property on the JVM using the -D flag does not result in an environment variable, this is explicitly a system property on the JVM.
We run our micronaut integration tests in the cloud in a docker container
We're setting the MICRONAUT_ENVIRONMENTS=staging in the docker environment variables, to force our application to read the config values from application-staging.yaml.
However, micronaut is automatically adding "test" as an environment, and then read the config values from application-test.yaml.
From the docs (https://docs.micronaut.io/2.2.1/guide/index.html#propertySource), environment variables should have priority compared to deduced environments when loading the config
Is there any reason why micronaut is giving priority to the application-test.yaml values here?
The test environment is added when micronaut tests are running, even when setting up the environment variable MICRONAUT_ENVIRONMENTS
After a bit of digging, it seems the "test" environment is added before the DefaultEnvironment class is initialized, hence it's added even if micronaut.env.deduction is set to false
In the Solr logs I see error -
java.lang.UnsupportedOperationException: Serialization support for
org.apache.commons.collections.functors.InvokerTransformer is disabled for
security reasons. To enable it set system property
'org.apache.commons.collections.enableUnsafeSerialization' to 'true',
but you must ensure that your application does not de-serialize
objects from untrusted sources.
I am trying to add flag -Dorg.apache.commons.collections.enableUnsafeSerialization=true, but it don't help.
How to correctly enable this property? (I haven't access to the solrconfig.xml)
You can add it to SOLR_OPTS environment variable or pass it directly to start script:
bin/solr start -Dorg.apache.commons.collections.enableUnsafeSerialization=true
As per Configuring solrconfig.xml docs:
In general, any Java system property that you want to set can be passed through the bin/solr script using the standard -Dproperty=value syntax. Alternatively, you can add common system properties to the SOLR_OPTS environment variable defined in the Solr include file (bin/solr.in.sh or bin/solr.in.cmd).
Is it possible to set the contents of Spring's bootstrap.properties at execution time?
I have a client application for Spring's cloud config which holds a line to point to the config server:
spring.cloud.config.url = http://localhost:8888
And I would like to set this config. I tried setting it like application.properties can be set:
java -jar ./config-client.jar --spring.cloud.config.url=http://localhost:8888
But it didn't work. So my question is, how can I set this property at execution time?
It seems to be caused by wrong properties name. url should be uri.
Try to change your property in bootstrap.properties like below.
spring.cloud.config.uri = http://localhost:8888
And then try again like below.
java -jar ./config-client.jar --spring.cloud.config.uri=<something else>
http://localhost:8888 is the default value of spring.cloud.config.uri. That's probably the reason why you didn't recognize the wrong property name.
Working with OWASP's ESAPI, I found myself stuck at this particular line of code.
private static String customDirectory = System.getProperty("org.owasp.esapi.resources");
The code returns null as there is no such system property "org.owasp.esapi.resources" set on my computer. Is there any way to set this property on my computer permanently?
You need to pass it into your JVM as a command line property. Most application containers use the environment variable JAVA_OPTS as a "permanent" store of options that should be passed to the JVM. You can try to do something like this:
In *nix:
export JAVA_OPTS="-Dorg.owasp.esapi.resources=/path/to/esapi/configuration"
In windows:
set JAVA_OPTS="-Dorg.owasp.esapi.resources=C:\path\to\esapi\configuration"
You can add this to windows or linux as a startup command and it will always be set if you desire, or add it to your application's startup script for a more localized solution.
If you put the ESAPI.properties and Validation.properties inside the resources folder it will recognize automatically.
In case you need to specify s specific folder or sub-folders, one possibility is adding this property in your standalone.
<system-properties>
<property name="org.owasp.esapi.resources" value="C:/.../resources/esapi"/>
<system-properties>
However, in unit tests, you have to specify before the tests.
#BeforeClass
public static void before() {
if(System.getProperty("org.owasp.esapi.resources") != null) {
System.out.println(System.getProperty("org.owasp.esapi.resources"));
} else {
System.setProperty("org.owasp.esapi.resources", "src/main/resources");
}
}