1

I have environmental variable called ENV, which holds the DEV,QA OR PROD region as value. When the server.xml loaded it includes the corresponding db configuration using this variable. For ex: db-config-${env.GAH_ENV}.xml

I would like to pass the same value to the batch job xml as a job parameter or properties to any of the class. How Can I do that.

below code snippet not working

<property name="environment" value="${env.GAH_ENV}"/>
user3540722
  • 175
  • 1
  • 2
  • 11
  • 1
    There's a built-in substitution for system properties, but not env vars. Let me ask, are you looking to get this value simply to inject it as a `@BatchProperty` into your batch artifacts? If that's all you might instead using MicroProfile Config and inject it into a `@ConfigProperty`. If this sounds like it would help, I could explain in more detail. On the other hand, if you really want/need the value as a JSL property, to use in other JSL property substitutions, APIs, etc., then that still leaves you with a problem. – Scott Kurz Sep 16 '19 at 17:04
  • Yes, I would need as @BatchProperty. But would like to read it from linux server environmental variables. For ex. From the linux profile environment. currently exported GAH_ENV variable read by server.xml to load db configuration. But I couldn't able to read that for job xml. – user3540722 Sep 16 '19 at 17:37
  • I understand you want to provide the value by using an environment variable. Just trying to understand if you really need to use a `@BatchProperty`. Let me ask you this: are you able/willing to change the Java artifact with the `@BatchProperty` injection point ? (Or must you leave the Java alone?). – Scott Kurz Sep 16 '19 at 19:09
  • @ScottKurz Yes, I can change that property. Shouldn't be an issue. Goal is to read from environmental variable. whatever works, I can try that. – user3540722 Sep 17 '19 at 01:28

1 Answers1

0

The short answer is that using a batch property may not be a good solution and you might consider something else like MicroProfile's @ConfigProperty.

The reason is there's not a built-in way to access environmental variables through JSL substitution. There is also not a convenient way for one artifact to set a property value to be used by a second artifact running later within the job execution.

In the special case that you are starting the job from within the same JVM it will execute, of course, you could pass the env var value as a job parameter.

But in the general case, if you can change the Java code and you don't really need a batch property I would use a MicroProfile Config property instead, injected via @Inject @ConfigProperty.

By doing so you lose the batch-specific substitution precedence, including the override available via job parameters passed with the submit/start. You also give up the ability to use this property in other JSL substitutions (to "compose" its value into other batch properties via other substitutions).

But you at least get a property with its own various levels of precedence/override (e.g. server config, env var, microprofile-config.properties), which is more flexible than just always reading the env var via System.getenv( ).

This is certainly an area to consider for the next version of the (now-Jakarta) Batch spec.

Scott Kurz
  • 4,985
  • 1
  • 18
  • 40