Yes, I think it's a CACHERESTXQ bug. The handler I posted earlier triggers it. Not sure what exactly triggers it.
Yes, if only we had a time machine. Kidding aside, REST services/microservices/UI clients/Javascript frameworks all are pushing on REST. I was triggered by recent developments by Facebook/Netflix and recently summarized in a talk on InfoQ called "Demand Driven architecture" (https://qconnewyork.com/ny2015/presentation/demand-driven-architecture). I think that it solves issues for UI clients. I'm looking into which forum to raise the issue or if I should just do the pragmatic thing, use POST, and shut up. I'm a bit scared for "religuous fanatism". ;-)
On Tue, Aug 4, 2015 at 12:01 PM, Christian Grün christian.gruen@gmail.com wrote:
I figured it out. The way to repro is with the function I posted earlier. Start the server but with CACHERESTXQ=true. Test the function: works fine. Change the handler function/file and save it. Retry the POST, boom. NPE. Switching CACHERESTXQ=false no fixes this.
I see; so it seems to be a CACHERESTXQ bug, right? (Andy: thanks as well).
Maybe I get crucified for saying this but I think we should allow GET with body.
Maybe even Roy agrees with you today, but we should probably have intervened and fixed that 20 years ago ;) We could obviously weaken the RESTXQ constraints, but it may be advisable to first check out if there has been a similar discussion on JAX-RS.
And yes, it's very useful and can simplify
clients that need to specify complex queries to a REST server. I stop ranting now, I probably should take this somewhere else but I'm still building up courage to do so ;-)
On Tue, Aug 4, 2015 at 11:05 AM, Christian Grün christian.gruen@gmail.com wrote:
All existing test cases seem to work, and I didn't come across this in my simple queries. Could you please provide me with a function and call that triggers the exception?
On Tue, Aug 4, 2015 at 11:00 AM, Marc van Grootel marc.van.grootel@gmail.com wrote:
I've double checked the version and manually downloaded latest. I'm now on BaseX 8.3 beta e13a5f0 which I assume is correct.
Not sure what's going on but in most cases (with format=map) gives me a NPE (and {"foo": "bar"}):
Unexpected error: Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk@mailman.uni-konstanz.de Version: BaseX 8.3 beta e13a5f0 Java: Oracle Corporation, 1.7.0_25 OS: Windows 7, amd64 Stack Trace: java.lang.NullPointerException at org.basex.http.restxq.RestXqFunction.parse(RestXqFunction.java:124) at org.basex.http.restxq.RestXqModule.process(RestXqModule.java:100) at org.basex.http.restxq.RestXqFunction.process(RestXqFunction.java:109) at org.basex.http.restxq.RestXqServlet.run(RestXqServlet.java:44) at org.basex.http.BaseXServlet.service(BaseXServlet.java:64) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:503) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:724)
On Tue, Aug 4, 2015 at 10:48 AM, Marc van Grootel marc.van.grootel@gmail.com wrote:
Hi Christian,
I pulled it via the Maven repo using Gradle. It says BaseX 8.3 beta 7f8299f. Maybe that doesn't carry the latest?
Re format name suggestions: format=item (not good, includes XML nodes), format=function (correct per http://www.w3.org/TR/xpath-datamodel-31/#types-representation as it includes array and map) but confusing. format=native (maybe?)
I agree fully that the server should have the last say in how to process the content so I would definitely be in favor of prioritizing server parameters. Not sure if that breaks something out there though.
--Marc
On Tue, Aug 4, 2015 at 10:31 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Marc,
> I can get this to work with %input:json format=direct/format=basic but > when I change to format=map I still get > > [bxerr:BASX0003] Input could not be converted: "POST.xml" (Line 1): No > text allowed before root element.
Hm, it seems to work on my machine. Here is again the minimized version (I also tried the function you sent to me; I removed the %rest:consumes and %rest:produces annotations, because they only serve as filters, and do not influence the conversion of $query):
declare %rest:POST("{$query}") %rest:path("/json") function local:json($query) { $query };
curl -XPOST -H"Content-Type:application/json;format=map" -Tinput.json "http://localhost:8984/json"
Are you sure you tried the latest snapshot?
> A second point regarding format=map. Not sure if this is the correct > name as I could be posting "[1,2,3]" which is valid JSON. Does this > mean there should be a format=array or would it be better to give a > different name for this format.
This is a valid point. It stems from the beginnings of that feature, where the top object was always a map. Do you possibly have a suggestion for a better name?
> A last point I would like to make is that I still find it dubious that > the client can specify things in a header (Content Type) that override > the way it's porcessed on the server.
I think it's basically a good idea to allow a client to specify content-type parameters. But it's true that the server parameter should probably be priorized and overwrite a client parameter, instead of the other way round. Do you agree?
Christian
-- --Marc
-- --Marc
-- --Marc