Hi Christian,
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.
About the conversion. I'm fine with the default being parse into XML as long as i can fix it to parse as array/map using a handler annotation (and in a way that the client cannot mess with this). No need to change defaults.
Maybe the wrong forum here but that REST discussion:
Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics.
What is that supposed to mean (pun intended)? If with semantics they mean HTTP verb semantics. Eg. GET is idempotent etc. then my use case where the body is simply an easier way to specify a query to the server and thus fully compatible with GET semantics. I see no difference with providing params via the URL string or path. Somehow in the past somebody (not sure if it was Fielding himself, maybe the people from the HTTP spec) decided body should not be part of a GET and all that needs to be done with GET semantics can be done with query strings. Now I'm forced to use POST which HTTP semantics are create a new resource. To me this seems worse then using GET and most implementers have chosen to conflate specs with "morals" (the REST morals). I already found out that going for GET is useless as the road is riddled with tools and libraries that forbid you from doing so. And also ES had to allow the same queries to be POSTed instead of provided with GET. Maybe I get crucified for saying this but I think we should allow GET with body. 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