[
https://issues.apache.org/jira/browse/DAFFODIL-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790574#comment-17790574
]
Steve Lawrence commented on DAFFODIL-2864:
------------------------------------------
This might be related to DAFFODIL-697, which talks about setDistinguishedRoot
node not working correctly. That function has been long deprecated and removed,
but maybe has a similar underlying issue to withDistinguishedRoot.
However, for the 3.5 and 3.6 releases, a workaround should be to provide the
root to the {{compileSource}} function via the optional name/namespace
parameters. Something like this should work:
{code:java}
String rootName = null;
String rootNamespace = null;
if (distinguishedRootNode != null) {
rootName = ... // get from distinguishedRootNode
rootNamespace = ... // get from distingushedRootNode
}
ProcessorFactory processorFactory = compiler.compileSource(uri, rootName,
rootNamespace);
if (processorFactory.isError) {
...
}
{code}
In fact, this workaround is probably the better way to do it. When you call
{{compileSource}} without a name/namespace, I believe Daffodil does some amount
of work using the first element it sees in the schema (this might be a bug,
maybe we shouldn't do any work until the user calls pf.isError?). If you then
call ProcessorFactory.withDistinguishedRootNode, we're going to have to redo
some of that work with the new root node. So the previous work was just wasted
effort. I think the issue right now is that we just don't redo that work with
the new root, which is why this function has no effect. That said, the code
around this in 3.4 looks very similar to 3.5 and 3.6, so maybe this hunch is
wrong. Regardless, the above workaround should work as expected.
I'll continue to look into this to figure out the underlying cause.
> Regression in distinguished root node
> -------------------------------------
>
> Key: DAFFODIL-2864
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2864
> Project: Daffodil
> Issue Type: Bug
> Affects Versions: 3.5.0, 3.6.0
> Reporter: Claude Mamo
> Priority: Major
>
> We've updated from Daffodil 3.4 to 3.5. Following the update, one of our
> Smooks examples started failing. It appears that the distinguished root node
> set from the processor factory is now being ignored. The same behaviour
> occurs on Daffodil 3.6. I've created a test case which reproduces the
> unexpected behaviour here:
> [https://github.com/claudemamo/smooks-dfdl-cartridge/tree/daffodil-distinguishedRootNode-issue.]
> Running the following will give you an error:
> {code:java}
> mvn clean test
> -Dtest=org.smooks.cartridges.dfdl.FunctionalTestCase#testSmooksConfigGivenDistinguishedRootNode{code}
>
> The error is:
> {quote}
> Unparse Error: Expected element start event for ex:\{http://example.com}file,
> but received element start event for (invalid) \{http://example.com}record
> {quote}
> The expected start event should actually be
> _[http://example.com|http://example.com/]:record_ because this is what the
> distinguished root node is set to. The distinguished root node is set in this
> line of code:
> [https://github.com/claudemamo/smooks-dfdl-cartridge/blob/daffodil-distinguishedRootNode-issue/src/main/java/org/smooks/cartridges/dfdl/DfdlSchema.java#L154].
> I've checked the release notes for Daffodil 3.5 and nothing stands out. The
> test case passes on Daffodil 3.4. Any advice on what the problem could be?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
