Bug 5746

Summary: @Inject @BatchProperty should work for job level properties
Product: jbatch Reporter: reza_rahman
Component: TCKAssignee: ScottKurz
Status: RESOLVED MOVED    
Severity: enhancement CC: cf126330, issues, matias-uy
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: PC   
OS: Windows   
Whiteboard:

Description reza_rahman 2014-01-28 00:26:37 UTC
Currently this type of injection does not work in the RI which is surprising. The spec itself seems ambiguous as to whether job level properties can be injected.
Comment 1 ScottKurz 2014-01-28 15:33:30 UTC
Let me restate what I think you're saying.

If you have:

<job>
 <properties>
   <property name="x"...
     ...
    <step id="step1">
      <batchlet ..>
         <properties/>  <!-- EMPTY -->
</job>

Then you will NOT be able to inject this into the batchlet:

@BatchProperty(name="x") 

---
I'd have to agree with you that the spec doesn't make this extremely clear.

All I see now is that in Section 9.3 we have:

"Note batch properties are visible only in the scope in which they are defined."
---

Recognizing the ambiguity we did consult the mailing list, and, as I recall, we tried to enforce this behavior in the TCK (we had some other issues with properties so I'd have to go back and check if it's still enforced).

---

At least maybe we should add something here for the spec errata maintenance release we're working on currently.    (I'd do a more careful search to be sure we didn't have better language.

I wouldn't jump to look at changing this behavior though (e.g. in a possible 1.1), as it would seem to introduce compatibility issues.
Comment 2 ScottKurz 2014-02-13 20:27:07 UTC
Added the following two changes.  

Note the second is only peripherally related, I just used it as an opportunity to more precisely state the defaulting behavior when @BatchProperty is used without a corresponding JSL property.

---

1)  Added new section:

9.3.2	Scope of property definitions for @BatchProperty injection

The rules governing the definition of properties for injection via @BatchProperty deserve some extra explanation and an example.
For a given artifact, the only properties that are injectable via @BatchProperty are those which are defined at the level of the artifact itself (i.e. as children of the “properties” element which is in turn a child of the very element defining the artifact:  batchlet, reader, listener, etc.).
In particular, just because an artifact definition is contained (at some level of nesting) within a ‘job’ element and (for most artifacts) within a ‘step’ element as well, it is NOT the case that the job properties and step properties are themselves injectable into that artifact via @BatchProperty.     This is the case even though these job and step properties are available for resolving the artifact-level property definitions via the jobProperties substitution mechanism (see section 8.8.1.2) .

The following example should make this more clear:

Example JSL:
<job>
 <properties>
   <property name="x" value=”xVal”/>
     ...
    <step id="step1">
      <batchlet ref=”MyBatchlet”>
         <properties> 
             <property name=”y” value=”#{jobProperties[x]}”/>
         </properties>
 
Example Java (MyBatchlet from JSL above):
  // WON’T WORK! - There is no property ‘x’ in scope for this injection
  @Inject @BatchProperty(name="x");    

  // WILL WORK – Gets value ‘xVal’
  @Inject @BatchProperty(name="y");  

------------------------------------------------------------------------------

2) Changed the last portion of Section 9.3.1 to:

The value of the annotated field is assigned by the batch runtime if a corresponding property element with a matching name is specified in the JSL in the scope that applies to the batch artifact in question. If the JSL property value resolves to the empty string (either explicitly set to the empty string literal or resolving to an empty string via property substitution – see section 8.8), no assignment is made and the resulting value is undefined by the batch specification.    The resulting value might simply be the Java default value, however using various dependency injection technologies may produce different results.  The resultant behavior may be defined by the particular dependency injection technology used in the runtime environment and so is outside the scope of this specification.

Example:
import javax.inject.Inject;
import javax.batch.api.BatchProperty;
public class MyItemReaderImpl {
	@Inject @BatchProperty String fname;
}

Behavior:

When the batch runtime instantiates the batch artifact (item reader in this example),  it assigns  the 
value of the property with name equal to ‘fname’ provided in the job XML to the corresponding @BatchProperty field named ‘fname’.  If no value is defined in JSL, the Java default (null)  is assigned or some other default is provided by a particular dependency injection technology.
Comment 3 cf126330 2014-02-14 16:46:05 UTC
In the above example, [x] should be ['x']
<property name=”y” value=”#{jobProperties[x]}”/>

I also prefer to make artifact properties self-contained. Many batch artifacts are developed as off-the-shelf components, and assume no direct influence from their enclosing job or step properties.  If some artifact properties (flags, feature configurations, etc) are not defined, then the artifact class expects this property is not there and will use a sensible default.

@Named
public class MyReader implements ItemReader {
  //debug flag should be configured only thru myReader properties in job xml
  @Inject
  @BatchProperty
  private String debug;

  public void readItem() throws Exception {
    if(debug!=null) {...

    }

}
Comment 4 matias-uy 2014-09-20 18:28:26 UTC
Is this bug related to this other bug?:
https://java.net/bugzilla/show_bug.cgi?id=6420
Comment 5 ScottKurz 2014-09-22 13:43:50 UTC
(In reply to matias-uy from comment #4)
> Is this bug related to this other bug?:
> https://java.net/bugzilla/show_bug.cgi?id=6420

This "bug" (in 5746) turns out to be "working as designed", and the spec was updated to clarify this.

I haven't had a chance to look at Bug 6420 yet though.
Comment 6 matias-uy 2014-09-22 15:40:02 UTC
(In reply to ScottKurz from comment #5)
> (In reply to matias-uy from comment #4)
> > Is this bug related to this other bug?:
> > https://java.net/bugzilla/show_bug.cgi?id=6420
> 
> This "bug" (in 5746) turns out to be "working as designed", and the spec was
> updated to clarify this.
> 
> I haven't had a chance to look at Bug 6420 yet though.

I am sorry for the word's choice. I'm uruguaian and do not speak english like I would like (spanish is my matternal language). I did not mean that it was a bug of the framework. What I tried to say was if this thing that you were discussing was related with Bug 6420 (I am not sure that Bug 6420 is even a bug).

Thanks! Matias