Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StrictXmir.java throws XML document structures must start and end within the same entity #3726

Closed
volodya-lombrozo opened this issue Dec 22, 2024 · 16 comments
Assignees
Labels

Comments

@volodya-lombrozo
Copy link
Member

I've updated the jeo-maven-plugin up to 0.49.2 version: objectionary/jeo-maven-plugin@a0ddd50

Now StrictXmir throws the following exception:

Caused by: java.lang.IllegalStateException: org.xml.sax.SAXParseException; systemId: file:////Users/runner/work/jeo-maven-plugin/jeo-maven-plugin/target/its/spring-fat/target/xsd/XMIR-0.49.2.xsd; lineNumber: 339; columnNumber: 29; XML document structures must start and end within the same entity.
    at com.jcabi.xml.StrictXML.validate (StrictXML.java:299)
    at com.jcabi.xml.StrictXML.<init> (StrictXML.java:93)
    at com.jcabi.xml.StrictXML.<init> (StrictXML.java:84)
    at com.jcabi.xml.StrictXML.<init> (StrictXML.java:74)
    at org.eolang.parser.StrictXmir.<init> (StrictXmir.java:96)
    at org.eolang.parser.StrictXmir.<init> (StrictXmir.java:81)
    at org.eolang.jeo.representation.VerifiedEo.asXml (VerifiedEo.java:71)
    at org.eolang.jeo.representation.MeasuredEo.asXml (MeasuredEo.java:58)
    at org.eolang.jeo.representation.BytecodeRepresentation.toEO (BytecodeRepresentation.java:117)
    at org.eolang.jeo.Disassembling.transform (Disassembling.java:86)
    at org.eolang.jeo.Caching.tryTransform (Caching.java:93)
    at org.eolang.jeo.Caching.transform (Caching.java:63)
    at org.eolang.jeo.Logging.transform (Logging.java:83)
    at org.eolang.jeo.Disassembler.disassemble (Disassembler.java:113)
    at org.eolang.jeo.ParallelTranslator.translate (ParallelTranslator.java:70)
    at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:195)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1655)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:484)
    at java.util.stream.ForEachOps$ForEachTask.compute (ForEachOps.java:290)
    at java.util.concurrent.CountedCompleter.exec (CountedCompleter.java:746)
    at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:290)
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1020)
    at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1656)
    at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1594)
    at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:183)
Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity.
    at org.apache.xerces.jaxp.validation.Util.toSAXParseException (Unknown Source)
    at org.apache.xerces.jaxp.validation.DOMValidatorHelper.validate (Unknown Source)
    at org.apache.xerces.jaxp.validation.ValidatorImpl.validate (Unknown Source)
    at javax.xml.validation.Validator.validate (Validator.java:124)
    at com.jcabi.xml.StrictXML.validate (StrictXML.java:282)
    at com.jcabi.xml.StrictXML.<init> (StrictXML.java:93)
    at com.jcabi.xml.StrictXML.<init> (StrictXML.java:84)
    at com.jcabi.xml.StrictXML.<init> (StrictXML.java:74)
    at org.eolang.parser.StrictXmir.<init> (StrictXmir.java:96)
    at org.eolang.parser.StrictXmir.<init> (StrictXmir.java:81)
    at org.eolang.jeo.representation.VerifiedEo.asXml (VerifiedEo.java:71)
    at org.eolang.jeo.representation.MeasuredEo.asXml (MeasuredEo.java:58)
    at org.eolang.jeo.representation.BytecodeRepresentation.toEO (BytecodeRepresentation.java:117)
    at org.eolang.jeo.Disassembling.transform (Disassembling.java:86)
    at org.eolang.jeo.Caching.tryTransform (Caching.java:93)
    at org.eolang.jeo.Caching.transform (Caching.java:63)
    at org.eolang.jeo.Logging.transform (Logging.java:83)
    at org.eolang.jeo.Disassembler.disassemble (Disassembler.java:113)
    at org.eolang.jeo.ParallelTranslator.translate (ParallelTranslator.java:70)
    at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:195)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1655)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:484)
    at java.util.stream.ForEachOps$ForEachTask.compute (ForEachOps.java:290)
    at java.util.concurrent.CountedCompleter.exec (CountedCompleter.java:746)
    at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:290)
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1020)
    at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1656)
    at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1594)
    at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:183)

Here you can find the failed pipeline: https://github.com/objectionary/jeo-maven-plugin/actions/runs/12433923236/job/34716515344?pr=942

All files and directories during the failure: https://github.com/objectionary/jeo-maven-plugin/actions/runs/12433923236/artifacts/2349006127

XSD file:
XMIR-0.49.2.xsd.txt

Log file:
build.log.txt

@volodya-lombrozo
Copy link
Member Author

@yegor256 @maxonfjvipon Could you take a look, please?

@volodya-lombrozo
Copy link
Member Author

Critical blocker for objectionary/jeo-maven-plugin#942

@volodya-lombrozo
Copy link
Member Author

@maxonfjvipon, do you have any progress here? This is a somewhat urgent matter.

@maxonfjvipon
Copy link
Member

@volodya-lombrozo yes, working on it, the main problem is the jcabi-xml thread unsafety. Should be fixed today

@volodya-lombrozo
Copy link
Member Author

@maxonfjvipon Awesome, thank you. Waiting for it.

@yegor256
Copy link
Member

@maxonfjvipon jcabi-xml 0.33.3 was released, you can try to use it

maxonfjvipon added a commit to maxonfjvipon/eo that referenced this issue Dec 25, 2024

Verified

This commit was signed with the committer’s verified signature.
lebauce Sylvain Baubeau
…nized
maxonfjvipon added a commit to maxonfjvipon/eo that referenced this issue Dec 25, 2024
github-merge-queue bot pushed a commit that referenced this issue Dec 25, 2024
…ict-xmir

bug(#3726): Updated jcabi-xml and made `StrictXmir` synchronized
@yegor256
Copy link
Member

@rultor release, tag is 0.49.3

@rultor
Copy link
Contributor

rultor commented Dec 25, 2024

@rultor release, tag is 0.49.3

@yegor256 OK, I will release it now. Please check the progress here.

@rultor
Copy link
Contributor

rultor commented Dec 25, 2024

@rultor release, tag is 0.49.3

@yegor256 Done! FYI, the full log is here (took me 11min).

@yegor256
Copy link
Member

@volodya-lombrozo try version 0.49.3 please

@volodya-lombrozo
Copy link
Member Author

@yegor256 What is the current API of StrictXmir? How should I use it?
Current implementation gives me compile time errors:

new StrictXmir(new XMLDocument(xmir)).validate();

@maxonfjvipon
Copy link
Member

maxonfjvipon commented Dec 25, 2024

@volodya-lombrozo we've changed the XML interface. You don't need to use .validate() explicitly on StrictXmir, it will be done automatically once you "touch" the object. So if you do .validate() it'll just validate it twice

@volodya-lombrozo
Copy link
Member Author

@volodya-lombrozo we've changed the XML interface. You don't need to use .validate() explicitly on StrictXmir, it will be done automatically once you "touch" the object. So if you do .validate() it'll just validate it twice

@maxonfjvipon I've read the code. Since I don't use the XML interface and I don't need to process StrictXmir somewhere else, In order to validate it, I need to use new StrictXml(new XMLDocument(xml)).inner(). To me, this API is counterintuitive. Why do we need open validate method then? @yegor256 Do you agree with such a design?

@yegor256
Copy link
Member

yegor256 commented Dec 25, 2024

@volodya-lombrozo this is a good question, but more related to jcabi-xml repository. Quick answer: in order to validate XML, you use xml.validate() (returns a list of errors); in order to validate+log, you decorate StrictXML(xml) and then use it, expecting an exception later (when you call .inner(), for example).

@volodya-lombrozo
Copy link
Member Author

@yegor256 I can't use xml.validate() without an XSD document. Moreover, what is the difference between StrictXmir and StrictXML classes then? I thought, StrictXmir is supposed to know about the XSD it validates against, but seems I'm wrong.

@volodya-lombrozo
Copy link
Member Author

@yegor256 @maxonfjvipon Ok, it's a separate story. Anyway the new solution doesn't work:
#3760

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants