Add test for Bug 5746 - @Inject @BatchProperty should work for job level properties

[scottkurz]

https://java.net/bugzilla/show_bug.cgi?id=5746

[jvfullam]

After reading through the discussion for Bug 5746 as well as the updated JSR 352 spec, it sounds like the conclusion that was made was that @​Inject @BatchProperty should not work for job level properties.

---

From the spec:

Example JSL:

     ...                             ... **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"); --- If my understanding is correct, then this issue should really be asking that a test be added that makes sure job level properties are **not** in scope of @​Inject @BatchProperty

[scottkurz]

Exactly.

I copied and pasted the bug description as it was originally opened, but you're right, unless you understand that it's a historical description you'd reach the exact opposite conclusion. Sorry about the confusion.

[jvfullam]

To add to the confusion, the following test already exists:

---

/*

• @​testName: testPropertyInnerScopePrecedence
• @​assertion: A batch artifacts properties overrides any parent properties defined in
• an outer XML scope. Child properties always override parent properties with the same name.
• @test_Strategy: Issue a job with a step level property and batchlet property with the same name.
• Verify that the injected property value is from the artifact level property. */ @​Test @org.junit.Test public void testPropertyInnerScopePrecedence() throws Exception { ... }

---

As we've determined, the parent properties should be out of scope (no need to be overridden). Does this test serve some other purpose? If not, it does not seem like good practice to keep it as part of the TCK.

Either way, a test still needs to be added to make sure that parent properties are in fact out of scope... working on this now.

[scottkurz]

@jvfullam - Good point regarding testPropertyInnerScopePrecedence, I agree. I think a way to salvage this flawed test would be to change the property def to:

<job id="job_properties2" ...>
    ...
        <batchlet ref="myBatchletWithPropertiesImpl">
            <properties>
                           ...
                <property name="batchletProp" value="#{jobProperties['batchletProp']}" />

and check that the step-level prop value of STEP_OVERRIDE is used rather than the job level.

I imagine that this was the intent at one time but it was implemented wrongly.

[scottkurz]

Looks good, we can close this now.