Note that these links are bad now, but we had it archived. Pasting it here starting with the 2016 discussion
From Roberto Cortez 22 April 2016
Hi,
I'm seeing different behaviours between implementations ofÂ
javax.batch.operations.JobOperator#getRunningExecutions:
RI and Spring Batch throw a NoSuchJobException if they can't find a
running Job with the passed name or if the name doesn't exist at all.
JBeret returns an empty list if the Job exists but there is no Job
running with the passed name. It throws the NoSuchJobException as normal if
it can't find the Job name.
The spec doesn't seem clear on what should be the behaviour if the Job
actually exists in the Repository, but is not running when the
getRunningExecutions method is called. At least I was not able to find any
clarification.
Also, I had a look into the TCK and it seems there is no test for this
particular situation.
Javadocs state:
/* Returns execution ids for job instances with the specified name
that have running executions. @param jobName       specifies
the job name. @return a list of execution ids. @throws
NoSuchJobException @throws JobSecurityException /
My understanding by reading this, is that the JBeret implementation is the
right one. A Job was found, but there are not current executions, so no id's
are returned (an empty list).
I would say, that for me, it doesn't seem right to throw a NoSuchJobException
just because there are not running instances. If the Job indeed does not
exists in the Repository, there is no way to distinguish both situations.
Scott, what do you think?
Cheers,Roberto
From Cheng Fang on 16 Feb 2015
Some methods in JobOperator interface throw NoSuchJobException in case of a non-exist jobName is passed in as param. It works for action methods like start, restart, and abondon, because the runtime cannot fulfill the request and NoSuchJobException is the right way to communicate this failure.
But for other getter methods (e.g., getJobInstanceCount, getJobInstances, getRunningExecutions, etc), NoSuchJobException seems to be confusing:
In its current form, client has to try catch NoSuchJobException, and test for 0 or null result for something not in the repository. Would it be easier for client if getJobInstanceCount just returns 0, when either the jobName does not exist, or an existing job contains no JobInstance? getJobInstances and getRunningExecutions return empty list when either the jobName does not exist, or an existing job contains no JobInstance or running JobExecution?
Job repository format is implementation-specific, and the client cannot reliably predict if a job that executed 10 days ago still exists in the repository. A historical job may be cleared anytime with implementation-specific means:
Section 11.2
All job repository artifacts are created by the batch runtime during
job processing and exist until deleted by an implementation provided
means.
Originally opened as bug 7647 by ScottKurz
--------------Original Comment History---------------------------- Comment from = ScottKurz on 2016-04-25 15:52:30 +0000
See discussions: https://java.net/projects/jbatch/lists/public/archive/2016-04/message/4
https://java.net/projects/jbatch/lists/public/archive/2015-02/message/4
Note that these links are bad now, but we had it archived. Pasting it here starting with the 2016 discussion
From Roberto Cortez 22 April 2016
Hi, I'm seeing different behaviours between implementations of javax.batch.operations.JobOperator#getRunningExecutions:
RI and Spring Batch throw a NoSuchJobException if they can't find a running Job with the passed name or if the name doesn't exist at all.
JBeret returns an empty list if the Job exists but there is no Job running with the passed name. It throws the NoSuchJobException as normal if it can't find the Job name.
The spec doesn't seem clear on what should be the behaviour if the Job actually exists in the Repository, but is not running when the getRunningExecutions method is called. At least I was not able to find any clarification. Also, I had a look into the TCK and it seems there is no test for this particular situation. Javadocs state: /* Returns execution ids for job instances with the specified name that have running executions. @param jobName       specifies the job name. @return a list of execution ids. @throws NoSuchJobException @throws JobSecurityException / My understanding by reading this, is that the JBeret implementation is the right one. A Job was found, but there are not current executions, so no id's are returned (an empty list). I would say, that for me, it doesn't seem right to throw a NoSuchJobException just because there are not running instances. If the Job indeed does not exists in the Repository, there is no way to distinguish both situations. Scott, what do you think? Cheers,Roberto
From Cheng Fang on 16 Feb 2015
Some methods in JobOperator interface throw NoSuchJobException in case of a non-exist jobName is passed in as param. It works for action methods like start, restart, and abondon, because the runtime cannot fulfill the request and NoSuchJobException is the right way to communicate this failure.
But for other getter methods (e.g., getJobInstanceCount, getJobInstances, getRunningExecutions, etc), NoSuchJobException seems to be confusing:
In its current form, client has to try catch NoSuchJobException, and test for 0 or null result for something not in the repository. Would it be easier for client if getJobInstanceCount just returns 0, when either the jobName does not exist, or an existing job contains no JobInstance? getJobInstances and getRunningExecutions return empty list when either the jobName does not exist, or an existing job contains no JobInstance or running JobExecution?
Job repository format is implementation-specific, and the client cannot reliably predict if a job that executed 10 days ago still exists in the repository. A historical job may be cleared anytime with implementation-specific means:
Section 11.2 All job repository artifacts are created by the batch runtime during job processing and exist until deleted by an implementation provided means.
Cheng