Bug 4551 - Parameter scoping
Parameter scoping
Product: jbatch
Classification: Unclassified
Component: source
All All
: P5 critical
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2013-01-17 23:02 UTC by mminella
Modified: 2013-01-18 20:03 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description mminella 2013-01-17 23:02:27 UTC
In section 6.3 on page 75, the spec notes that batch properties are scoped (visible only within the scope they are defined).  This introduces a number of questions/issues:

1.  How does inheritance work with that?  
2.  How are parameters scoped when provided to the JobOperator#start()?
3.  This is also vastly different from the previous version of the spec (we previously never explicity said that parameters would be scoped like that).

It has always been my assumption that parameters were global and the user could use naming conventions for scoping if they desired.
Comment 1 ScottKurz 2013-01-18 04:07:55 UTC
Michael, since this wording came partially at my request, let me jump in. 

The fact that you would even have a question at this point to me suggests the spec could use an example here.. 

Let's be clear about the difference between parameters and properties.  

Job parameters are passed in on JobOperator.start() as the 2nd parameter on method:
   JobOperator.start(String jobXMLName, Properties jobParameters)

Batch properties in Sec 6.3 are defined in JSL to be injected into batch artifacts (on fields annotated with @Inject @BatchProperty).

A batch property can get its value either as a JSL literal, or through any of the substitution mechanisms defined in Sec. 5.7.
 - job parameters
 - job properties
 - system properties, etc.
Further "job properties" is explained to encompass properties defined at any scope of JSL .. i.e. they could have been called "JSL properties" maybe...

So job parameters are indeed global.   

The point of the language I request here is to make clear the following use case:

Say I have passed in a jobParameters Properties object with Property of name=A and one with name=B into JobOperator.start().    Then for a JSL like:

<step ...>
     <property name="A" value="#{jobParameters['A']}"/>     
 <batchlet... >
       <property name="B" value="#{jobParameters['B']}"/>     

I can do:

 public class MyBatchlet extends AbstractBatchlet
  @Inject @BatchProperty(name="B")

but not:

 public class MyBatchlet extends AbstractBatchlet
  @Inject @BatchProperty(name="A")

The fact that there's a step property named A, which "contains" the batchlet 
definition, is irrelevant.   There is no @BatchProperty named "A"...

If you wanted to define one, you could use the 'jobProperties' syntax for
a value via property substitution... but you'd have to define one AT THE BATCHLET LEVEL in JSL.

As far as inheritance... please give a bit more detail what you think is ambiguous.

Comment 2 mminella 2013-01-18 19:19:28 UTC

1.  I was unaware that batch properties and parameters were two different things.  I had the understanding that a job property (as defined in 6.3) was just a way to inject a parameter.
2.  While your description confirms my understanding of parameters as a global thing, it introduces the concept of properties (at least to me).  It sound like (from your description) that a batch property is nothing more than a way to inject a string value into a instance of a class with the sources of that string being the JobXML, job parameters, system properties, etc.  Is that correct?
Comment 3 cvignola 2013-01-18 19:21:48 UTC
Yes, that is correct.
Comment 4 mminella 2013-01-18 19:40:12 UTC
Ok...I guess if DI is not required, then this is a necessary evil.