iceScrum | API creation of tasks via XML – iceScrum

iceScrum Forums Discuss on iceScrum

Viewing 3 posts - 1 through 3 (of 3 total)

  • Author
  • #10709



    I’m unable to create tasks using the API.

    I’ve been able to create stories, update stories, accept stories, plan stories to a sprint, get all features, get all sprints, and get all tasks using the API fairly well.

    Here are 3 cURL requests that I made in series (with some information replaced):

    curl -H “Accept: application/xml” -u user:password -k –request GET http://xxxxxxxx/icescrum/ws/p/PKEY/story/83

    curl -H “Accept: application/xml” -u user:password -k –request GET http://xxxxxxxx/icescrum/ws/p/PKEY/sprint/3

    curl -H “Accept: application/xml” -u user:password -k –request POST –verbose http://xxxxxxxx/icescrum/ws/p/PKEY/task -d “833CLAIM TASK<

    The first 2 were successful; however, the 3rd request which is were I attempted to create the task had failed, and I believe it printed a stack trace. Here’s part of the response:

    Grails Runtime Exception

    Grails Runtime Exception

    Error Details

    Error 500: Executing action [save] of controlle
    r [] caused exception: Cannot i
    nvoke method remove() on null object

    Servlet: grails

    URI: /icescrum/grails/task/save.dispatch

    Exception Message: Cannot invoke method
    remove() on null object

    Caused by: Cannot invoke method remove(
    ) on null object

    Class: CorsFilter

    At Line: [66]

    Code Snippet:

    Stack Trace

    java.lang.NullPointerException: Cannot invoke method remove()



    at grails.plugin.springcache.web.GrailsFragmentCachingFilter.doFilter(Gr

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec

    at java.util.concurrent.ThreadPoolExecutor$

    Any idea what I could have been doing wrong? Is there any more information that would be helpful for me to provide?



    Nicolas Noullet


    There was two problems:
    – The Accept header was set but the Content-Type one was required. This one is very strange because the library we use should treat the Accept and the Content-Type headers in the same way (which is not a good thing, but as far as I know it was enforced). I must give another look at this problem.
    – The id of sub-resources must be included as attributes
    The documentation was wrong about that so we have fixed it.

    Here is an example of a working curl command that creates a task :

    curl -H "Content-Type: application/xml" -u user:password -k --request POST --verbose http://xxxxxxxx/icescrum/ws/p/PKEY/task -d "CLAIM TASK"


    Thank you! I’m currently circumventing this issue by just using JSON, but it seemed like it was a problem with data returned as XML attributes. Hopefully, this will fix the problem I’ve been having.

    I was already setting both accept and content-type as “application/xml” in my code for all requests, but I had only been specifying one in my curl requests.
    I also had issues with and in creating stories and updating stories, which I have been circumventing by using the separate 2 requests for specifically associating a feature or planning in a sprint, but this probably resolves those issues as well.

Viewing 3 posts - 1 through 3 (of 3 total)

The forum ‘Questions and help’ is closed to new topics and replies.