Hi Christian,

It absolutely makes sense to me that the exception is shown here in general (when using -d).

I just wonder why the exception is not catched somewhere before, as it is possible to load a file instead of a named database with fn:doc. So I wouldn't expect an exception to be thrown at all here. Or at least I would expect that the exception is catched, as soon as the program knows that no actual error ocurred - for the reason that it is plausible that a database with such name doesn't exist (because a file has been requested instead).

Best regards, Stefan

Am 07.11.19 um 18:33 schrieb Christian Grün:

Hi Stefan,

Our debugging output is very verbose; it outputs every internal exception that would get lost otherwise. In a future version, we may introduce different debugging/logging levels in order to reduce the debugging output.

In productive code, we recommend everyone to disable debugging. All critical errors will be sent to STDERR, so you shouldn’t lose anything.

Best, Christian

On Thu, Nov 7, 2019 at 4:18 PM Stefan Pöschel spoeschel@irt.de wrote:

...

Hello,

the XPath function "fn:doc" in BaseX can also be used to open a database (instead of an XML document).

However when I open an XML document and have debug messages enabled, an exception is shown that seems to be related to an (unsuccessful) attempt to open a database (meanwhile the fn:doc command itself succeeds):

---

org.basex.core.BaseXException: Database 'test.xml' was not found. at org.basex.core.cmd.Open.open(Open.java:92) at org.basex.query.QueryResources.data(QueryResources.java:405) at org.basex.query.QueryResources.doc(QueryResources.java:207) at org.basex.query.func.fn.Docs.doc(Docs.java:61) at org.basex.query.func.fn.FnDoc.item(FnDoc.java:17) at org.basex.query.func.StandardFunc.optimize(StandardFunc.java:82) at org.basex.query.expr.Arr.compile(Arr.java:43) at org.basex.query.func.StaticFunc.comp(StaticFunc.java:69) at org.basex.query.QueryCompiler.compile(QueryCompiler.java:114) at org.basex.query.QueryCompiler.compile(QueryCompiler.java:105) at org.basex.query.QueryContext.compile(QueryContext.java:312) at org.basex.query.QueryContext.iter(QueryContext.java:331) at org.basex.http.restxq.RestXqResponse.serialize(RestXqResponse.java:73) at org.basex.http.web.WebResponse.create(WebResponse.java:63) at org.basex.http.restxq.RestXqServlet.run(RestXqServlet.java:53) at org.basex.http.BaseXServlet.service(BaseXServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1700) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1667) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:505) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804) at java.lang.Thread.run(Thread.java:748)

---

Please find attached a minimal test XQM and a corresponding XML document. Both files have to be stored in the "webapp" subfolder of the folder from which BaseX is called.

With the option "WITHDB = false" in ".basex", the exception doesn't occur (which is not surprising). However I think that the exception shouldn't show up in the debug output here at all, as the fn:doc command actually succeeds (and as it "pollutes" the output).

I use BaseX 9.2.4 on Linux; the used cmdline is "basexhttp -d".

Thanks and best regards, Stefan -- Stefan Pöschel

IRT - Institut für Rundfunktechnik GmbH - https://www.irt.de

Research and Development Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmühlstr. 60, 80939 München, Germany

Registration court Munich Commercial, Register No. B 5191 Managing Director: Michael Hagemeyer

Hi Christian,

ah OK, now I see. For me the debug mode was equal to a verbose mode, but with your explanations it makes sense that this exception shows up.

Thanks and best regards, Stefan

Am 18.11.19 um 15:54 schrieb Christian Grün:

Hi Stefan,

In debugging mode, there are numerous exceptions that will be both caught by BaseX and sent to stderr (feel free to check out source code). Unexpected errors will also be dumped when debugging is disabled.

Cheers, Christian

Stefan Pöschel <spoeschel@irt.de mailto:spoeschel@irt.de> schrieb am Mo., 18. Nov. 2019, 15:39:

Hi Christian,

It absolutely makes sense to me that the exception is shown here in
general (when using -d).

I just wonder why the exception is not catched somewhere before, as it
is possible to load a file instead of a named database with fn:doc. So I
wouldn't expect an exception to be thrown at all here. Or at least I
would expect that the exception is catched, as soon as the program knows
that no actual error ocurred - for the reason that it is plausible that
a database with such name doesn't exist (because a file has been
requested instead).

Best regards,
        Stefan

Am 07.11.19 um 18:33 schrieb Christian Grün:
> Hi Stefan,
>
> Our debugging output is very verbose; it outputs every internal
> exception that would get lost otherwise. In a future version, we may
> introduce different debugging/logging levels in order to reduce the
> debugging output.
>
> In productive code, we recommend everyone to disable debugging. All
> critical errors will be sent to STDERR, so you shouldn’t lose
> anything.
>
> Best,
> Christian
>
>
>
> On Thu, Nov 7, 2019 at 4:18 PM Stefan Pöschel <spoeschel@irt.de
<mailto:spoeschel@irt.de>> wrote:
>>
>> Hello,
>>
>> the XPath function "fn:doc" in BaseX can also be used to open a
database
>> (instead of an XML document).
>>
>> However when I open an XML document and have debug messages
enabled, an
>> exception is shown that seems to be related to an (unsuccessful)
attempt
>> to open a database (meanwhile the fn:doc command itself succeeds):
>>
>> -----
>> org.basex.core.BaseXException: Database 'test.xml' was not found.
>>         at org.basex.core.cmd.Open.open(Open.java:92)
>>         at
org.basex.query.QueryResources.data(QueryResources.java:405)
>>         at
org.basex.query.QueryResources.doc(QueryResources.java:207)
>>         at org.basex.query.func.fn.Docs.doc(Docs.java:61)
>>         at org.basex.query.func.fn.FnDoc.item(FnDoc.java:17)
>>         at
org.basex.query.func.StandardFunc.optimize(StandardFunc.java:82)
>>         at org.basex.query.expr.Arr.compile(Arr.java:43)
>>         at org.basex.query.func.StaticFunc.comp(StaticFunc.java:69)
>>         at
org.basex.query.QueryCompiler.compile(QueryCompiler.java:114)
>>         at
org.basex.query.QueryCompiler.compile(QueryCompiler.java:105)
>>         at
org.basex.query.QueryContext.compile(QueryContext.java:312)
>>         at org.basex.query.QueryContext.iter(QueryContext.java:331)
>>         at
org.basex.http.restxq.RestXqResponse.serialize(RestXqResponse.java:73)
>>         at org.basex.http.web.WebResponse.create(WebResponse.java:63)
>>         at
org.basex.http.restxq.RestXqServlet.run(RestXqServlet.java:53)
>>         at org.basex.http.BaseXServlet.service(BaseXServlet.java:65)
>>         at
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>         at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865)
>>         at
>>
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
>>         at
>>
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>>         at
>>
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>>         at
>>
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>>         at
>>
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>>         at
>>
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1700)
>>         at
>>
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>>         at
>>
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>>         at
>>
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>>         at
>>
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>>         at
>>
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1667)
>>         at
>>
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>>         at
>>
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>>         at
>>
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>>         at
>>
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>>         at org.eclipse.jetty.server.Server.handle(Server.java:505)
>>         at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
>>         at
>>
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
>>         at
>> org.eclipse.jetty.io
<http://org.eclipse.jetty.io>.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>>         at org.eclipse.jetty.io
<http://org.eclipse.jetty.io>.FillInterest.fillable(FillInterest.java:103)
>>         at org.eclipse.jetty.io
<http://org.eclipse.jetty.io>.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
>>         at
>>
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698)
>>         at
>>
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804)
>>         at java.lang.Thread.run(Thread.java:748)
>> -----
>>
>> Please find attached a minimal test XQM and a corresponding XML
>> document. Both files have to be stored in the "webapp" subfolder
of the
>> folder from which BaseX is called.
>>
>> With the option "WITHDB = false" in ".basex", the exception doesn't
>> occur (which is not surprising). However I think that the exception
>> shouldn't show up in the debug output here at all, as the fn:doc
command
>> actually succeeds (and as it "pollutes" the output).
>>
>> I use BaseX 9.2.4 on Linux; the used cmdline is "basexhttp -d".
>>
>> Thanks and best regards,
>>         Stefan
>> --
>> Stefan Pöschel
>>
>> IRT - Institut für Rundfunktechnik GmbH - https://www.irt.de
>> ------------------------------------------------------------
>> Research and Development Institute
>> of ARD, ZDF, DRadio, ORF and SRG/SSR
>> Floriansmühlstr. 60, 80939 München, Germany
>>
>> Registration court Munich Commercial, Register No. B 5191
>> Managing Director: Michael Hagemeyer

-- 
Stefan Pöschel

IRT - Institut für Rundfunktechnik GmbH - https://www.irt.de
------------------------------------------------------------
Forschungs- und Entwicklungsinstitut
von ARD, ZDF, DRadio, ORF und SRG/SSR
Floriansmühlstr. 60, D-80939 München

Registergericht München, HRB 5191
Geschäftsführer: Michael Hagemeyer