[YANGTOOLS-611] YANG Parser (sometimes) has Source: null, making it hard to track which source model file an error is in Created: 12/May/16  Updated: 10/Apr/22  Resolved: 20/Nov/17

Status: Verified
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0

Type: Bug
Reporter: Michael Vorburger Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 5881

 Description   

In some cases at least, when the yangtools yang parser fails, it does not say WHERE (while processing WHICH *.yang file) it fell over. Strangely, I have seen a case (see below) where it gives a line / column information, but not which model file.

I'll see if I can contribute a change to address this.

[main] ERROR org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor - yang-to-sources: Unable to parse yang files from /home/vorburger/dev/ODL/git/controller/opendaylight/md-sal/samples/toaster-consumer/src/main/yang
java.lang.IllegalArgumentException: config:disable-osgi-service-registration is not a YANG statement or use of extension. Source: null:19:9
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)
at org.opendaylight.yangtools.yang.parser.impl.YangStatementParserListenerImpl.enterStatement(YangStatementParserListenerImpl.java:88)
at org.opendaylight.yangtools.antlrv4.code.gen.YangStatementParser$StatementContext.enterRule(YangStatementParser.java:113)
at org.antlr.v4.runtime.tree.ParseTreeWalker.enterRule(ParseTreeWalker.java:66)
at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:49)
at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:52)
at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:52)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.YangStatementSourceImpl.writeFull(YangStatementSourceImpl.java:94)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.SourceSpecificContext.loadStatements(SourceSpecificContext.java:320)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.loadPhaseStatements(BuildGlobalContext.java:206)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.buildEffective(BuildGlobalContext.java:174)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.CrossSourceStatementReactor$BuildAction.buildEffective(CrossSourceStatementReactor.java:105)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.CrossSourceStatementReactor$BuildAction.buildEffective(CrossSourceStatementReactor.java:123)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.processYang(YangToSourcesProcessor.java:169)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.execute(YangToSourcesProcessor.java:93)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute(YangToSourcesMojo.java:116)

 Comments   
Comment by Robert Varga [ 12/Jul/16 ]

Well, a file name is not necessarily available, as it can be something loaded in memory or similar. Getting line/column is something that can be done from any data stream.

I think in this particular case the model is being resolved from a dependency jar – but steps to reproduce would be helpful.

Comment by Igor Foltin [ 17/Oct/16 ]

Hi Michael, are you currently working on this bug ? If so, could you please set the status to IN_PROGRESS and also the target milestone. Otherwise put it back into the queue. Thx

Comment by Robert Varga [ 05/Mar/17 ]

This boils down to migrating downstreams to use yang-test-util with appropriate methods, such that the stream identity is not lost. For that we may need a couple of new methods.

Comment by Robert Varga [ 26/Oct/17 ]

Fixed with elimination of https://git.opendaylight.org/gerrit/62537, which forces proper identity to be retained. Also previous work has migrated IllegalArgumentExceptions to SourceExceptions, which retain this information.

Generated at Wed Feb 07 20:53:46 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.