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