Dear Michael, Yes, RESTXQ is defined on top level in our web.xml file. Files that are located in the path of the default servlet won't be served by RESTXQ, but directly by the web server. The two remaining servlet mappings refer to REST and WebDAV, and both of them don't rely on RESTXQ either.
I must confess that our documentation [1] is not too verbose when it comes to the web.xml configuration; any contribution is more than welcome! Andy's XML configuration (which possibly stems from the web.xml file we used in the beginnings of RESTXQ) is exactly the way to go if you do not want to have RESTXQ on top level. As you correctly observed, there is no need to specify the default servlet if it points to the root path anyway. > any of > ... > elicited the response "Not found" (or sometimes "no > function found"), but I found no entries for these requests > in the BaseX logs. (And I was unsuccessful in attempting to > turn Jetty's stderr or request logging on.) If the message says "No function found", it means that there is no RESTXQ path defined for the supplied path. This info should be stored in the BaseX logs. In the other cases, the message was returned by the web server, so we have no control over it. You are completely right, it would be helpful to activate Jetty's logging output in order to see what's going on. I have just added a new GitHub issue for your request [2]. There is also an older issue on logging [3]: We would like to redirect all BaseX logging output to a standardized logger, such as Log4J. It turned out that this is not as trivial as I hoped it would be, because BaseX provides so many different interfaces (CLI, GUI, Client/Server, HTTP), which all have different requirements. Thanks for your feedback! Christian [1] http://docs.basex.org/wiki/Web_Application [2] https://github.com/BaseXdb/basex/issues/1061 [3] https://github.com/BaseXdb/basex/issues/940
