Michael,

As Christian suggests the web.xml from GraphXQ does date from the old default basexhttp configuration (~basex 7.8?). Initially I was unconvinced by the change to what is the current default configuration but I have grown to appreciate it. 

This old configuration gives you a http server with a special path for RESTXQ. This is nice if you want to be able to just drop  resources into the webapp folder and have them served like a web server does, with a small or maybe even no, RESTXQ component.

The current web.xml configuration gives you a RESTXQ server with a special path for static files (/static/*.html etc). In my applications I try to design them so that the static part could be easily moved to separate server. A potential source of confusion with RESTXQ is that the path specified in the annotation is unaffected by the physical file path of the RESTXQ file.
  
If you look at the dba code  does not use /static at all  but serves static files by reading them from the file system and using RESTXQ to server them. This allows better control of the headers for caching etc. but is more work.

The nice thing is that once you understand the web.xml configuration you can choose either style.

/Andy
      

On 22 January 2015 at 21:11, Christian Grün <christian.gruen@gmail.com> wrote:
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