This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.
To start at the beginning, follow the link to the first post.
The next post in the series is here.
Every element of the JSL that defines a batch job can have properties that can be injected into that artifact. A listener can have properties that are injected into it, an itemReader can have properties injected into it, even a partitionMapper can have properties injected into it. But it turns out the job itself can have properties. How do you get to those?
The JobContext comes to our rescue. We talked about the JobContext last time and about how it can be injected into any batch artifact. We noted that separate threads of execution in the job get their own JobContext object instance. But no matter how many instances of the JobContext you have, they all have access to the job properties.
After injecting the JobContext you just call the getProperties method and a Properties object will be returned to you. You can use that Properties object like any other and fetch values that are set in the JSL as properties at the job level. Often those properties get values from job parameters that were supplied when the job was submitted. That makes this a handy way for any part of the job to get access to the job parameters.
There are a couple of notes in the JobContext interface about the properties that are worth discussing. The first points out that the Properties object you get back isn’t necessarily some magic global Properties object you can access from anywhere. It might be that every time you get the Properties for the Job, you get a new, unique Properties object back.
Why is that important? It means that you shouldn’t SET properties into that object and expect them to go anywhere. It is tempting to use that Properties object to set values as a way to pass information to other parts of the job. But that isn’t safe because not all the users are necessarily getting the same Properties object. The vague wording in the specification means that while some implementations MIGHT give you back the same object and so setting properties into it might work, you can’t count on that behavior across implementations and so you shouldn’t depend on it.
The other note just points out that the implementation might ‘tuck’ other properties of its own into the JobContext properties so you shouldn’t be surprised to find things in there that weren’t in the JSL. The JobContext is a handy place for the JSR-352 implementation to hang things that are associated with the job. So don’t panic if you find something in there that you didn’t put there.
See you next time!
>>Next article in this series
<<Previous article in this series