[
https://issues.apache.org/jira/browse/DAFFODIL-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Thompson closed DAFFODIL-2374.
-----------------------------------
Verified the specified commit (commit 779e9803ba7708d700c0205cbd690a179841b084)
is included in the latest pull from the incubator-daffodil repository.
Verified the effected incubator-daffodil sbt test suites execute successfully.
Verified the nightly test schemas compile and save successfully.
Verified the nightly test suite executes successfully.
> Choice with dispatch on variable getting reset when parsing potentially nil
> elements
> ------------------------------------------------------------------------------------
>
> Key: DAFFODIL-2374
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2374
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 2.7.0
> Reporter: Josh Adams
> Priority: Major
> Fix For: 3.0.0
>
>
> Ran into this while developing schemas for a customer.
> The schema for this scenario looks something like this:
> <dfdl:defineVariable name="var" defaultValue="false" />
> ....
> <dfdl:setVariable ref="var" value="true" />
> ...
> <xs:choice dfdl:choiceDispatchKey="\{ $var }">
> <xs:sequence dfdl:choiceBranchKey="true">
> <xs:element name="name" type="xs:string" nillable="true">
> </xs:sequence>
> </xs:choice>
>
> What I believe is happening is that the nillable element is creates a mark in
> PState, which then gets reset as this element in the data is not nil. This
> causes PState to reset back to the mark, which also triggers any variables
> that were changed in the current scope to reset. In this case, the changes
> that have been tracked is the setVariable on var and the readVariable on var
> for the choice dispatch. So when reset gets called the variable is getting
> reset back to its initial default state of false.
>
> I believe the fix for this is to simply push a new list to the
> changedVariablesStack whenever we create a new mark and pop the stack after
> resetting any changed variables, but I have not spent a lot of time on it. It
> fixes the issue I have and does not break any existing tests though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
