Skip to main content

[jsr352-public] Re: job properties resolution order and self reference

  • From: Christopher Vignola < >
  • To:
  • Subject: [jsr352-public] Re: job properties resolution order and self reference
  • Date: Wed, 27 Mar 2013 08:20:53 -0400

foo=null

Here's why:

Spec section "8.8.1.2  jobProperties Substitution Operator" states resolution order is innermost scope to outermost - i.e. artifact, step, job.  

Spec section "8.8.1.6 Property Resolution Rule" states a property must be defined before it can be used in a substitution _expression_.  

Spec section "8.8.1.7 Undefined Target Name Rule" states a substitution _expression_ operator that specifies an undefined target name is assigned a null value."

Cheng brings up a great edge case.   I would argue that a property is not "defined" until it's value is assigned;  if it's value contains a substitution operator, that the value cannot be assigned until the substitution is resolved; that the substitution references the very target name being defined, but not yet finished being defined,  would fall under rule 8.8.1.7 and result in a value of null.

Chris Vignola, STSM, IBM
JSR 352 Spec Lead
WebSphere Systems Management Architect
phone: 1+(720) 396-7501
email:

http://chris.vignola.googlepages.com


Inactive hide details for Kaushik Mukherjee---03/27/2013 12:59:17 AM---Cheng,    The Batchlet level property in your example shKaushik Mukherjee---03/27/2013 12:59:17 AM---Cheng,    The Batchlet level property in your example should resolve to "foo" instead of null. I bel

From: Kaushik Mukherjee/Poughkeepsie/IBM@IBMUS
To:
Date: 03/27/2013 12:59 AM
Subject: [jsr352-public] Re: job properties resolution order and self reference





Cheng,  

The Batchlet level property in your example should resolve to "foo" instead of null. I believe  the Spec, RI, and TCK all resolve job properties from the outside elements to the inner elements, but inner job properties can still override outer job properties. So the TCK tests you are referring to are intentionally written to expect the job level value of foo. Are you saying that we should change the spec to resolve from inside out? Sorry if I didn't understand your question fully.

Thanks,
Kaushik
_____________________
Kaushik Mukherjee
WebSphere Batch Development



-----Cheng Fang < > wrote: -----

To:
From: Cheng Fang < >
Date: 03/26/2013 10:58PM
Subject: [jsr352-public] job properties resolution order and self reference

In the following xml, there is job-level property foo (resolved), and
also a batchlet-level property foo, declared to be
#{jobProperties['foo']}.  Which target should this reference resolve to?

<job>
    <properties>
        <property name="foo" value="foo"/>
    </properties>
    <step>
        <batchlet>
            <properties>
                <property name="foo" value="#{jobProperties['foo']}"/>
            </properties>

Since the resolution process starts from the innermost containment, and
inside batchlet, foo is already declared (though not resolved), I tend
to think it should resolve to itself, hence yield null.  I feel this is
more natural.  I noticed some TCK tests use this reference structure and
expect it resolved to the job-level one. What do you think?

Thanks,
Cheng

GIF image



[jsr352-public] job properties resolution order and self reference

Cheng Fang 03/27/2013

[jsr352-public] Re: job properties resolution order and self reference

Kaushik Mukherjee 03/27/2013

[jsr352-public] Re: job properties resolution order and self reference

Christopher Vignola 03/27/2013

[jsr352-public] Re: job properties resolution order and self reference

Kaushik Mukherjee 03/27/2013

[jsr352-public] Re: Re: job properties resolution order and self reference

Christopher Vignola 03/28/2013
 
 
Close
loading
Please Confirm
Close