Bug 4197

Summary: issues with JobPath (Sec 7.5), should it be in the spec?
Product: jbatch Reporter: ScottKurz
Component: sourceAssignee: cvignola
Status: CLOSED FIXED    
Severity: enhancement CC: issues
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: PC   
OS: Windows   

Description ScottKurz 2012-10-10 16:20:31 UTC
First, isn't the only use case for JobPath the inheritance use case given that JobOperator.submit() requires the full JSL as a String (rather than a path/location)? 


My bigger issue is I'm having a hard time understanding why the spec needs to prescribe where to find the JSL files.   

What if my JEE-based implementation wants to define its own construct for allowing certain JSL to serve as the implementation to other child JSL(s)?  Are you saying it must first look at this "javax.jobpath" mechanism?  

Or is this rule only for JSE implementations maybe?  

What piece of code/script/etc. am I allowing to remain common across implementations?

If we want to define a new batch packaging format, then we could certainly come up with rules for importing/exporting from these packages.   

But if we're not going in that direction, it seems it might be enough for this spec to define what the artifacts should look like, and not where in the filesystem they should be placed/deployed.


If it is kept in the spec maybe it needs to be something more like a classpath in case it is zipped up in a JAR along with (or separately from) other batch artifacts.
Comment 1 cvignola 2012-10-10 16:47:48 UTC
This may be a case of possible implementation bleeding into spec.  I think you may be right that how the inheritance source is located need not be specified. We should not assume the way this needs to work in an SE environment vs a EE environment vs a future environment in which there is potentially an external batch scheduler is the same.

Let's try removing it from the spec and see how that holds up.
Comment 2 cvignola 2013-01-16 17:32:59 UTC
jobpath was removed.   META-INF/batch-jobs was added