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.gr...@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 >
