[jira] [Updated] (DAFFODIL-1816) Unit test rigs don't serialize parser/unparser - allows lazy evaluation during runtime.

["Mike Beckerle (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Beckerle updated DAFFODIL-1816:
------------------------------------
    Priority: Minor  (was: Major)

> Unit test rigs don't serialize parser/unparser - allows lazy evaluation during runtime.
> ---------------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-1816
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-1816
>             Project: Daffodil
>          Issue Type: Bug
>          Components: API, Front End, Infrastructure, TDML Runner
>            Reporter: Mike Beckerle
>            Assignee: Rick
>            Priority: Minor
>              Labels: beginner
>
> See also DFDL-1814 about CompilerMode/RuntimeMode.
> Developer reports that debugging tests in daffodil-core-unittest results in mixtures of compilation lazy evaluation with runtime.
> These test rigs used for these unit tests do not serialize/unserialize the parser nor unparser before invoking them. It is the serialization that ultimately forces all the lazy evaluation that the compiler performs to be forced.
> In theory, these mixtures can only occur if nobody calls "isError" on the ProcessorFactory and then the DataProcessor objects, as that is supposed to cause all the requiredEvaluation(...) forms to evaluate, and that should force everything that is needed to insure the object is without error.
> In practice, not everything gets caught that way, and serialization of the parser/unparser runtime objects is the thing that ultimately forces everything (specifically the pre-serialization call).
> To fix this we need a synchronized method on Processor that keeps a local object state indicating that the processor has been serialized. If the object is serialized normally by way of call to save() then the local flag should be set. If not, then serializing the object to a /dev/null stream should occur so as to force all the lazy evaluation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)