3

When I ran a job multiple times on the liberty server it allways takes the parameter values of my first job ran although I changed the values. So I can't run the job multiple times with different parameter values. Why? What happens if I run several of the same jobs in parallel with different parameters?

My JSL looks like:

job id="VerbrauchsfolgeExecutor" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
  <properties>
    <property name="stichtag" value="#{jobParameters['stichtag']}" />
    <property name="filename" value="#{jobParameters['filename']}" />
    <property name="filetype" value="#{jobParameters['filetype']}" />
    <property name="groupSize" value="#{jobParameters['groupSize']}" />
    <property name="db2Umgebung" value="#{jobParameters['db2Umgebung']}" />
    <property name="loglevel" value="#{jobParameters['loglevel']}" />
  </properties>
  <step id="STEP1">
    <chunk item-count="100">
      <reader ref="VerbrauchsfolgeReader"></reader>
      <processor ref="VerbrauchsfolgeProcessor"></processor>
      <writer ref="VerbrauchsfolgeWriter"></writer>
    </chunk>
  </step>
</job>

Reading the properties:

...
@Inject
JobContext context;
...
Properties prop = context.getProperties();
String loglevel = prop.getProperty("loglevel");
...

Job call:

...
.\batchManager submit --jobXMLName=VerbrauchsfolgeExecutor --applicationName=zos-verbrauchsfo
lge-1.0.0 --user=bob --trustSslCertificates --batchManager=localhost:9082 --jobParameter=stichtag=25.03.2022 --jobParame
ter=filename=dataset.out --jobParameter=filetype=RDW --jobParameter=groupSize=10 --jobParameter=db2Umgebung=E11 --jobPar
ameter=loglevel=INFO
...

This is not the behavior I expect when running a job multiple times in a row with different parameter values. Please, can someone help me with my problem.

Scott Kurz
  • 4,985
  • 1
  • 18
  • 40
hsterkel
  • 33
  • 4
  • First let's make sure you're not getting mixed up between job properties and job parameters. The **JobContext#getProperties()** method returns the properties not the parameters. If you want to set a property using a similarly-named parameter you'd follow a pattern like [this](https://github.com/WASdev/sample.batch.sleepybatchlet/blob/master/src/main/webapp/WEB-INF/classes/META-INF/batch-jobs/sleepy-batchlet.xml#L26-L28) simple example. From the Java class point of view the property value could come from a parameter or another source. If this doesn't help can you post a JSL snippet? – Scott Kurz Aug 22 '22 at 13:39
  • Also, you're not using an @ApplicationScoped on your batch artifact (that you're accessing the JobContext Properties from) by any chance are you? – Scott Kurz Aug 22 '22 at 16:02
  • @scottkurz: I wrote down the whole JSL now. The properties define the parameters of the job and the method getProperties() returns the given values of the parameters. When I ran the job the second time with different values in the jobParameters, the changes in the values are not considered. – hsterkel Aug 22 '22 at 16:06
  • Unfortunately I use the annotation @ApplicationScoped on my batch artifact. – hsterkel Aug 22 '22 at 16:10
  • When I remove and update the application in the liberty the changed values are used. – hsterkel Aug 22 '22 at 16:22
  • OK, so that sounds like the original behavior was working as designed then. – Scott Kurz Aug 22 '22 at 16:59

1 Answers1

2

ANSWER

Don't use an @ApplicationScoped annotation with a batch artifact that needs per-job instance data (if you are going to run more than one job per application startup). Maybe an alternative would be to use a @Dependent scope for the batch artifact and move per-application-lifecycle instance data into a separate @ApplicationScoped bean which can then be injected into the batch artifact.

Explanation

Batch artifacts can be loaded as CDI Beans and the instances are scoped similarly, e.g. for a batch artifact annotated with @ApplicationScoped the container is only going to load a single instance of that type for each time the application is started. This is part of how Jakarta Batch and CDI integrate together within the Jakarta Platform.

Scott Kurz
  • 4,985
  • 1
  • 18
  • 40
  • Many Thanks for the explanation. I will try the proposal with the per-application-lifecycle instance. Another idea is using a file. Do you think this is good idea? At the end the job should run on the host. Do you know a good description about Websphere and the Jakarta Platform? – hsterkel Aug 22 '22 at 20:10
  • I'm not sure of a good resource diving into Batch + CDI usage patterns, though I've come across a few questions here on StackOverflow. A good intro to Jakarta Batch in general is: https://www.baeldung.com/java-ee-7-batch-processing A resource for Liberty Batch specifically is: https://www.ibm.com/support/pages/ibm-websphere-liberty-java-batch (though there's more operational than API info here). Finally, I'm not sure I understand your file idea, but if you'd like to chat with the Open Liberty dev team try us on Gitter at: https://gitter.im/OpenLiberty/developer-experience. – Scott Kurz Aug 22 '22 at 20:59
  • I changed the annotation in all batch artifacts (reader, processor and writer) from \@ ApplicationScoped in \@Dependent. An additional class named 'AppContext' is now also annotated with \@Dependent. In this class I inject the JobContext and I use the TransientUserData of the class JobContext to save all the data used in the (reader, processor and writer). 'AppContext' is injected in (reader, processor and writer). I'm not sure if I really understand everything, but ... it's working. I can now change the properties (jobParameter), ran the job again and the changed values are used. I'm happy. – hsterkel Aug 23 '22 at 11:10
  • It seems like I don't really need a batch artifact annotated with /@ApplicationScoped. – hsterkel Aug 23 '22 at 11:22
  • 1
    OK, glad that works for you! And if you found that something like 'AppContext' worked better with a different scope you could always explore adding the scope annotation (e.g. @ApplicationScoped) to it. (Also, you might upvote and/or accept the answer too then.) – Scott Kurz Aug 23 '22 at 13:16