Bug 4866

Summary: SPEC Partition Properties example has a invalid </properties> tag
Product: jbatch Reporter: arunkumar_s
Component: SPECAssignee: cvignola
Status: NEW ---    
Severity: minor CC: issues, kmukher, ScottKurz
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: PC   
OS: Windows   
Whiteboard: 1.0_mr_pending

Description arunkumar_s 2013-04-01 10:49:08 UTC
In PFD 1.7

Under 8.2.6.2 Partition Properties example

<partition> 

<plan partitions="2"> 

<properties partition="0"> 
<property name="filename" value="/tmp/file1.txt"/> 
</properties> 

<properties partition="1"> 
<property name="filename" value="/tmp/file2.txt"/> 
</properties> 

</properties> 
</partition


Last two lines of xml is wrong. 
First there shouldnt be a </properties> tag in the second last line. It should be </plan>
Second the </partition should end with >
Comment 1 ScottKurz 2013-11-25 15:27:22 UTC
Corrected typos in XML snippet for Partition Properties example;  corrected partition number description by changing from "positive" to "non-negative" (Section 8.2.6.2).
Comment 2 ScottKurz 2014-01-16 15:35:14 UTC
As Cheng noticed recently, we have a similar issue in Sec. 8.8.1.2

E.g. The batch runtime would attempt resolution of the jobProperties operator specification in the following chunk definition by first searching the chunk properties collection, then the step properties collection (if any), then the job properties collection (if any). The search would stop at the first occurrence of the specified target name. 

<job id="job1"> <properties> <property name="filestem" value="postings"/> </properties> <step id="step1"> <chunk> <properties> <property name="infile.name" value="#{jobProperties['filestem']}.txt"/> </properties> </chunk> </
Comment 3 ScottKurz 2014-02-13 12:23:06 UTC
Fixed example in Section 8.8.1.2 to conform to XSD and better explain that you can use a jobProperties substitution from an earlier property in the current sequence (same scope).

It now reads:
------------------------------------------------------------------------------
E.g.

The batch runtime would attempt resolution of the jobProperties operator specification in the following  reader property definition by first searching for earlier property definitions within the reader properties collection, then the step properties collection (there are none in this example), then the job properties collection (if any).  The search would stop at the first occurrence of the specified target name.  

<job id="job1">
<properties>
  <property name="filestem" value="postings"/>
</properties>
 <step id="step1">
  <properties/>
  <chunk>
    <reader ref=”MyReader”> 
	<properties>
      	  <property name="infile.name"                        
 				value="#jobProperties['filestem']}.txt"/>
	</properties>
    </reader>
  </chunk>
 </step>
</job>

The resolved value for property "infile.name" would be "postings.txt".
Comment 4 kmukher 2014-02-14 21:37:05 UTC
Since the example mentions the search order of property resolution it would help to include it right in the XML so we don't have to qualify the statement with "there are none in this example".

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

The batch runtime would attempt resolution of the jobProperties operator specification in the following reader property definition by first searching for earlier property definitions within the reader properties collection, then the step properties collection, then the job properties collection (if any). The search would stop at the first occurrence of the specified target name. 

<job id="job1"> 
    <properties> 
        <property name="filestem" value="postings"/> 
        <property name="outputlog" value="jobmessages"/> 
    </properties> 
    <step id="step1"> 
        <properties/> 
        <chunk> 
            <reader ref=”MyReader”> 
                <properties> 
                    <property name="infile.name" value="#{jobProperties['filestem']}.txt"/> 
                    <property name="ouputtlog" value="readermessages"/> 
                    <property name="outfile.name” value="#{jobProperties[‘outputlog’]}.txt"/> 
                </properties> 
            </reader> 
        </chunk> 
    </step> 
</job> 

The resolved value for property "infile.name" would be "postings.txt".
The resolved value for property "outfile.name" would be "readermessages.txt".
Comment 5 ScottKurz 2014-02-14 21:56:53 UTC
Kaushik, 

I can incorporate that example too alongside the other.   It still doesn't have any properties at the step properties level, but it now shows substitution from an earlier property at the "same level" alongside the other one, and so clarifies that the search is inner to outer.    This means that override is outer to inner (by that I mean that inner overrides outer which I think is natural).

Here's how it reads now:

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

8.8.1.2	jobProperties Substitution Operator

The jobProperties substitution operator resolves to the value of the job property with the specified target name.  This property is found by recursively searching  from the innermost containment scope to the outermost scope until a property with the specified target name is found. 

E.g.
The batch runtime would attempt resolution of the jobProperties operator specification in each of the two following  reader property definitions by first searching for earlier property definitions within the reader properties collection, then the step properties collection (there are none in this example), then the job properties collection (if any).  The search stops at the first occurrence of the specified target name.  

<job id="job1">
	<properties>
		<property name="filestem" value="postings"/>
		<property name="outputlog" value="jobmessages"/>
	</properties>
	<step id="step1">
		<properties/>
		<chunk>
			<reader ref=”MyReader”> 
				<properties>
					<property name="infile.name"  value="#{jobProperties['filestem']}.txt"/>
					<property name="ouputtlog"  value="readermessages"/> 
					<property name="outfile.name”  value="#{jobProperties['outputlog']}.txt"/> 
				</properties>
			</reader>
		</chunk>
	</step>
</job>

The resolved value for reader property "infile.name" would be "postings.txt".
The resolved value for reader property "outfile.name" would be "readermessages.txt".
Comment 6 ScottKurz 2014-02-14 22:00:04 UTC
Rephrased slightly:

The jobProperties substitution operator resolves to the value of the job property with the specified target name.  This property is found by recursively searching  from the innermost containment scope (this includes earlier properties within the current scope) to the outermost scope until a property with the specified target name is found.

---

Just wait for the full PDF to review if this is too much to assemble.
Comment 7 ScottKurz 2014-03-24 14:17:13 UTC
(In reply to ScottKurz from comment #5)

In above, new example, change:
 <property name="ouputtlog"  value="readermessages"/> 
to:
 <property name="outputlog"  value="readermessages"/> 

Thanks to Michael for noticing that.