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