org.sbml.jsbml.xml.XMLNode cannot be cast to org.sbml.jsbml.Annotation

[ntung]

Dear The JSBML Developers Team,

BioModels has some curated models with the issue. These models were curated for a while but they run into this problem. The problem broke down our index pipeline. Would you be able to escalate the problem?
BIOMD0000000596, BIOMD0000000794, BIOMD0000000849, BIOMD0000000925, BIOMD0000000965.

java.lang.ClassCastException: org.sbml.jsbml.xml.XMLNode cannot be cast to org.sbml.jsbml.Annotation
	at org.sbml.jsbml.xml.stax.SBMLReader.readXMLFromXMLEventReader(SBMLReader.java:851)
	at org.sbml.jsbml.xml.stax.SBMLReader.readSBMLFromStream(SBMLReader.java:554)
	at org.sbml.jsbml.xml.stax.SBMLReader.readSBMLFromStream(SBMLReader.java:564)
	at org.sbml.jsbml.SBMLReader.readSBMLFromStream(SBMLReader.java:251)
	at org.sbml.jsbml.SBMLReader$readSBMLFromStream.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
	at net.biomodels.jummp.indexing.indexer.SBMLIndexer.extractFileContent(SBMLIndexer.groovy:129)

I have seen another user reporting the problem at #263.

[Schmoho]

Hi! I am not a JSBML dev, but I looked into your issue because I am also encountering it.

The model annotation (on the <model> element) of this file is invalid SBML, because the layout-information is within the annotation object. This looks like an error (not adherent to the layout-package spec) likely introduced by COPASI. Moving the <layout:listOfLayouts> tag out of the <annotation> tag "solves" the issue apparently.

However, I would still consider this a bug in JSBML; at the very least, this should have a more informative error message.

[Schmoho]

I just realized, the SBML is not actually invalid:

1. SBML 2.4 did not know packages, so the use of the <layout:listOfLayouts> container on the <model> level would not actually be valid and that also means that the layout information in this model is not actually subject to the SBML layout-package spec.
2. The SBML spec does not seem to actually specify that an annotation cannot contain another annotation, so JSBML expecting this is divergent from the spec.

[fbergmann]

Layout and render specify precisely how to deal with it in case of SBML Level 2 documents:

https://raw.githubusercontent.com/combine-org/combine-specifications/main/specifications/files/sbml.level-3.version-1.layout.version-1.release-1.pdf

The file has been modified after being exported by COPASI. The layout element is in the wrong namespace. I can attach a valid l2v4 and l3v1 example.
LeBeau1999_Phosphorylation_CCK.xml.l2v4.txt
LeBeau1999_Phosphorylation_CCK_l3v1.xml.l3v1.txt

[Schmoho]

I see.
As far as I understand it though, this doesn't change that the SBML is valid in principle (because you can put arbitrary stuff in an annotation), which kind of raises the question if the way JSBML fails on this is not needlessly confusing for a user that is not familiar with the specs.

Also the models that are affected range from 2015 to 2019 and across a number of working groups - this strongly suggests to me that some software agent and not manual manipulation is responsible for this.

[fbergmann]

Indeed and regardless how those files came to be, JSBML should log it as error but still proceed with the parsing of the files. It would be simple enough to check the type before the cast.

[ntung]

Thank you @Schmoho for pointing out the actual root cause. It seems that we can update SBML documents to sort the problem out. I completely agree with @fbergmann in term of developer's perspective.

[ntung]

Indeed and regardless how those files came to be, JSBML should log it as error but still proceed with the parsing of the files. It would be simple enough to check the type before the cast.

@fbergmann Could you suggest a feasible solution to fix it?

[dyrpsf]

Hi @draeger , @Schmoho , @matthiaskoenig , @ntung and @fbergmann ,

I’ve opened a PR to address this issue: #282 .

The ClassCastException comes from org.sbml.jsbml.xml.stax.SBMLReader when it reaches the end of an <annotation> element. The code was unconditionally doing:

((Annotation) lastElement).getParent()

and passing that to the registered AnnotationReaders. For some models (e.g. with a layout:listOfLayouts block inside the model annotation), the top of the stack is not actually an Annotation but an XMLNode, so this cast fails with:

org.sbml.jsbml.xml.XMLNode cannot be cast to org.sbml.jsbml.Annotation

The PR changes this to:

• check that lastElement is an Annotation and that its parent is an SBase before calling processAnnotation, and
• otherwise log an error and skip annotation parsing for that element, without throwing an exception.

So JSBML will now continue parsing the file even if the annotation structure is unexpected, which is what was suggested in the discussion here.

I also added a small regression-style test (SBMLReaderAnnotationCastTest.layoutInModelAnnotationDoesNotThrow) that reads a minimal L2V4 SBML string with a layout:listOfLayouts element inside the model annotation and asserts that SBMLReader.readSBMLFromString(...) returns a document with a model (i.e. no ClassCastException).

On my side, mvn -pl core test passes with this change.