On 01/14/2014 03:10 PM, Christian Grün wrote:
Since I don't want to make everything "updating", because I dont want to introduce unnecessary synchronization, I'd like to just call the native functions through the forwarding mechanism passing ahead the POST content of the request and exploiting the nice declarative way of routing with parametric path annotations. […]
I guess I should spend more time on understanding your use case, but due to my lazyness, I’m just asking why you don’t directly call the functions instead of using redirects? À la…
OLD: (: do all SOAP related work here :) rest:forward{ "test/impl" }</rest:forward>
NEW: (: do all SOAP related work here :) soapskel:impl($postbody)
If it makes sense.. Do you have an example that demonstrates why this isn’t possible?
Sorry, for sure this is possible. But suppose I have different impl functions where few of them are updating and few are not. I necessarily have to declare the soap entry point as updating too. Thus introducing particular syntax like db:output or synchronizations in places where it's not supposed to be needed. Isn't it like that?
According to the optionality of the postbody parameter it works when I call a RESTXQ function directly. It also works when forwarding if the orignal HTTP request doesn't have any postbody. But when the postbody is there in the original request, the subsequent function (where I forward to) yields the error.
I just tried your example with the following curl call. As expected, it returns nothing, but it doesn’t raise an error either:
curl -i -XPOST -d"<a/>" "localhost:8984/test"
HTTP/1.1 200 OK Content-Type: application/xml; charset=UTF-8 Content-Length: 0 Server: Jetty(8.1.11.v20130520)
I think it depends on the content type. I'm trying with firefox poster and it works if I force application/x-www-form-urlencoded. Conversely it stops working with
curl -i -XPOST -d"<a/>" -H "Content-Type: application/xml; charset=UTF-8" "localhost:8984/test"
Thanks a lot anyway. M.