|
Note: JobIdentifier is removed, but JobParameters are the same thing a developer would need access to, so the issue is still there.
I moved this to 2.0. I don't think there's anyway we could solve this beyond the convenience method currently in place without making more changes than would be acceptable in a point release.
What about adding a static class to manage the job parameters for a given execution?
e.g. JobParametersHolder.getJobParameters() caveat: threadsafety is an issue if multiple jobs running in same JVM probably could handle this with a ThreadLocal? ThreadLocal won't work if you launch the job in another thread, or if the reader/writer is accessed in multiple threads (most of the framework implementations do not support this, but it's not that unusual). I can't see how this would work at all in that case, except if you knew the JobExecution id. And if you knew that you would know the job parameters anyway.
If I understand ThreadLocals properly, the purpose of the ThreadLocal would be to hold a separate immutable copy of the JobParameters for each thread - a lot of threads would have the same exact information, but I'm not sure why you think it wouldn't work as part of a potential strategy. It may take some more components to make it work (e.g. adding some logic that would have each new thread retrieve the job parameters for its corresponding execution from the repository and store it in its thread local via static method call, etc.). The idea of using a static call with a ThreadLocal would just be so all this is handled automatically and stored in memory by the executing class (task executor?) instead of having to go to the repository using the execution id to retrieve your parameters, which it seems is what you're implying by saying "if you knew that you would know the job parameters anyway"
The only other n=1 option I can think of is to make an Aware implementation and create a stock JobExecutionListener that injects this into each Aware artifact (i.e. readers / writers for item oriented, the injected tasklet for tasklet step), but this requires much more configuration to work. *having to go to the repository using the execution id
should read having to go to the repository using the execution id or calling a 5-level deep accessor method |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Make input parameters easier to access from ItemReaders, etc.
stepContext.getStepExecution().getJobExecution().getJobInstance().getJobIdentifier().
I'm okay with JobIdentifierAware, I'm not sure if I would go so fine grained as InstancePropertiesAware though.