Hi Christian, Thank you!
I am going to try not to need that catalog pragma, but it's good to know that it's there. Graydon On Thu, May 15, 2025, at 03:21, Christian Grün wrote: > Hi Graydon, > > With the latest snapshot, the unexpected stack trace will be correctly caught > [1]. The default behavior of the standard resolver can be changed with a > system property [2]. We’ll think about adding Norm’s resolver to the > distributions of BaseX. > > Cheers, > Christian > > [1] https://files.basex.org/releases/latest/ > [2] https://docs.basex.org/12/Catalog_Resolver#additional_notes > > > On Sun, May 11, 2025 at 5:13 PM Graydon Saunders <[email protected]> > wrote: >> __ >> Hi Gunther, >> >> Thank you! >> >> Dropping xmlresolver-6.0.14-data.jar and xmlresolver-6.0.14.jar from the zip >> release via https://github.com/xmlresolver/xmlresolver/releases into >> basex/lib/custom works. The document parses and the entities are resolved; I >> have the catalog set via "local options" in both .basex and .basexgui, so >> I'm going to think this is expected. And I can confirm that I don't need to >> explicitly set any options in doc() for things to work. >> >> I'm sure this is a much more complex issue than it seems to me, but perhaps >> it would be a useful thing to ship the open resolver with BaseX? >> >> Much appreciated, >> Graydon >> >> On Sun, May 11, 2025, at 06:01, Gunther Rademacher wrote: >>> Hi Graydon, >>> >>> thank you for reporting this. I was able to reproduce the behaviour that >>> you are seeing - not only with BaseX 11.9 and Java 21, but also with BaseX >>> 11.8 and Java 11. >>> >>> The root cause appears to be the standard JDK catalog resolver, >>> javax.xml.catalog.CatalogResolverImpl, which tends to throw a >>> CatalogException when a URI cannot be resolved via the catalog. >>> Unfortunately, BaseX does not currently handle this exception type. It >>> expects a TransformerException, which is why the process fails in your case. >>> >>> In my own environment, I’ve never encountered this issue because I always >>> have XML Resolver, i.e. org.xmlresolver.Resolver, on the classpath. This >>> resolver replaces the standard implementation and simply returns null when >>> a match isn’t found, rather than throwing an exception. >>> >>> I’ll open a GitHub issue to ensure that BaseX is updated to handle >>> CatalogException properly. In the meantime, a practical workaround is to >>> add XML Resolver to your classpath. I suspect you may already have it in >>> place in the environment where you tested BaseX 11.8, which could explain >>> why the issue didn’t surface there. >>> >>> Also, as you mentioned, fn:doc was recently updated. You can find more >>> about those changes in this discussion: >>> https://www.mail-archive.com/[email protected]/msg16163.html >>> >>> However, I don’t believe those updates are directly related to the issue >>> you're seeing. >>> >>> Best regards, >>> Gunther >>> >>> *Gesendet: *Sonntag, 11. Mai 2025 um 03:16 >>> *Von: *"Graydon Saunders" <[email protected]> >>> *An: *BaseX <[email protected]> >>> *Betreff: *[basex-talk] 11.9 doc() not working with DOCTYPE declaration >>> Hello -- >>> >>> I'm on linux, using 11.9 and using >>> >>> 20:59 graydon % java -version >>> openjdk version "21.0.7" 2025-04-15 >>> OpenJDK Runtime Environment (Red_Hat-21.0.7.0.6-1) (build 21.0.7+6) >>> OpenJDK 64-Bit Server VM (Red_Hat-21.0.7.0.6-1) (build 21.0.7+6, mixed >>> mode, sharing) >>> >>> If I use the basexgui "Create DB" dialog and the internal parser, I can >>> load the whole folder without error; I get the expected DB and the named >>> entities in the content have been resolved. (These are effectively HTML 4 >>> entity names, so that's not completely guaranteeing that the DTD in the >>> DOCTYPE is being found and parsed somewhere.) >>> >>> If I use the doc() function with an absolute file system path to one of the >>> same files that loaded into the DB just fine, I get an error. I get the >>> same error if I try to switch off the internal parser and set a catalog. >>> It's at least several files in the folder that loads fine as a DB. >>> >>> All of this works fine with 11.8; whatever changed changed in 11.9. >>> >>> The error is: >>> >>> Could not execute XQUERY >>> doc('/home/graydon/GeneralCode/git/cpc-conversion/Chapter/BU4372-14A.xml'): >>> Improper use? Potential bug? Your feedback is welcome: >>> Contact: [email protected] >>> Version: BaseX 11.9 >>> Java: Red Hat, Inc., 21.0.7 >>> OS: Linux, amd64 >>> Stack Trace: >>> javax.xml.catalog.CatalogException: JAXP09040002: No match found for href >>> '/home/graydon/GeneralCode/git/cpc-conversion/Chapter/BU4372-14A.xml' and >>> base '/home/graydon/GeneralCode/git/cpc-conversion/xquery/file'. >>> at >>> java.xml/javax.xml.catalog.CatalogMessages.reportError(CatalogMessages.java:74) >>> at >>> java.xml/javax.xml.catalog.CatalogResolverImpl.resolve(CatalogResolverImpl.java:153) >>> at org.basex.query.StaticContext.resolve(StaticContext.java:156) >>> at org.basex.query.StaticContext.resolve(StaticContext.java:137) >>> at org.basex.query.QueryInput.<init>(QueryInput.java:31) >>> at org.basex.query.func.fn.Docs.queryInput(Docs.java:37) >>> at org.basex.query.func.fn.Docs.lambda$accept$0(Docs.java:67) >>> at org.basex.query.scope.LockVisitor.lock(LockVisitor.java:48) >>> at org.basex.query.func.fn.Docs.accept(Docs.java:56) >>> at org.basex.query.scope.MainModule.databases(MainModule.java:93) >>> at org.basex.query.QueryContext.addLocks(QueryContext.java:412) >>> at org.basex.query.QueryProcessor.addLocks(QueryProcessor.java:230) >>> at org.basex.core.cmd.AQuery.addLocks(AQuery.java:170) >>> at org.basex.core.locks.Locking.acquire(Locking.java:86) >>> at org.basex.core.jobs.Job.register(Job.java:48) >>> at org.basex.core.Command.execute(Command.java:90) >>> at org.basex.gui.GUI.execute(GUI.java:430) >>> at org.basex.gui.GUI.lambda$execute$5(GUI.java:375) >>> at java.base/java.lang.Thread.run(Thread.java:1583) >>> >>> I can go on using 11.8 for now, so this is only somewhat alarming rather >>> than completely alarming. >>> >>> -- Graydon >>
