OK, now I see the problem - the problem is that the curl PUT statement in the existing roo_deploy.sh does not include the id of the json object being put. This is one of the things which I added to roo in order to comply with the REST spec. The current curl statement is just trying to PUT to the entire list as follows:

curl -i -s -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -o /tmp/rootest/curl.txt -d "{id:6,name:\"Mozzarella\",version:1}" http://localhost:8888/pizzashop/toppings

Instead, if we simply add "/6" to the end, as we correctly do later in the GET of that particular element, we get the desired results:

curl -i -s -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -o /tmp/rootest/curl.txt -d "{id:6,name:\"Mozzarella\",version:1}" http://localhost:8888/pizzashop/toppings/6

It does seem a little redundant that the id is also included in the payload, but I think this is how we are supposed to do this. See http://stackoverflow.com/questions/4477454/how-is-a-http-put-request-typically-issued and http://blogs.plexibus.com/2009/01/15/rest-esting-with-curl/ for a couple of discussions around this.

I've updated roo-deploy.sh with the above curl and the script completes without errors now.

There is one last curl statement that is commented out, and I think it never worked. If you're willing to have a go at fixing it, please feel free. It creates a pizzaorder. PizzaOrder has a composite primary key.

curl -i -s -X POST -H "Content-Type: application/json" -H "Accept: application/json" -o /tmp/rootest/curl.txt -d "{name:\"Stefan\",total:7.5,address:\"Sydney, AU\",deliveryDate:1314595427866,id:{shopCountry:\"AU\",shopCity:\"Sydney\",shopName:\"Pizza Pan 1\"},pizzas:[{id:8,version:1}]}" http://localhost:8888/pizzashop/pizzaorders	

- line 303 of roo-deploy.sh now

I think one reason that the more complex pizzashop post operations aren't working is because if you take a look at the pizzashop.roo which is provided in the roo resources directory, there is no "toppings" element included in a Pizza element. A Pizza entity currently only seems to consist of a name and a price:

entity jpa --class ~.domain.Pizza --testAutomatically
field string --fieldName name --notNull --sizeMin 2
field number --fieldName price --type java.lang.Float

So when you try to include toppings on a pizza as a part of a PizzaOrder entity, things get a little confused.

When I add a reference to a set of toppings to a pizza like this:

entity jpa --class ~.domain.Pizza --testAutomatically
field string --fieldName name --notNull --sizeMin 2
field number --fieldName price --type java.lang.Float
field set --fieldName toppings --type ~.domain.Toppings

..I can get through the first of the two complex post tests (pizzas) with a 200 result:

curl -i -s -X POST -H "Content-Type: application/json" -H "Accept: application/json"  -o /tmp/rootest/curl.txt -d "{name:\"Napolitana\",price:7.5,base:{id:1},toppings:[{name: \"Anchovy fillets\"},{name: \"Mozzarella\"}]}" http://localhost:8888/pizzashop/pizzas

...you can see how it successfully adds the new "Napolitana" pizza to pizzas, as well as the new "Anchovy fillets" topping to toppings. This seemed OK at first, but I guess I would really want to see a 201 [CREATED] return here instead.

I can also get through the second complex post test (pizzaorders) with a 200 result, but an error still occurs shortly after this command. If you leave the second test commented out, the rest of the test script seems to complete normally, so that would sort of implicate the second of the two complex post statements.

In fact, the JPA error only occurs after both tests have completed, and just as the Tomcat server is being terminated, so the actual error may have more to do with the way the tomcat server is being terminated than anything else.

One other thing to consider is that these (ROO-3376) roo changes shouldn't effect existing post behavior. The only thing approaching post behavior which was removed was a PUT of a list of items - which really kind of goes against the REST spec according to the original defect report - as a list should probably either be posted, PUT as an object with its own id, or individually PUT one element at a time. That is not to say that we don't still have an issue here, it's just that it doesn't really seem like part of this Jira.

The net result is, this Jira is stuck with a remaining complex curl statement that seems to somehow cause a JPA error at some point after it [successfully?] completes with a 200 result:

curl -i -s -X POST -H "Content-Type: application/json" -H "Accept: application/json" -o /tmp/rootest/curl.txt -d "{name:\"Stefan\",total:7.5,address:\"Sydney, AU\",deliveryDate:1314595427866,id:{shopCountry:\"AU\",shopCity:\"Sydney\",shopName:\"Pizza Pan 1\"},pizzas:[{id:8,version:1}]}" http://localhost:8888/pizzashop/pizzaorders     

Here is the pizzaorders data from the curl statement formatted in hopes of eyeballing whether or not all of these entities are accurately represented here in json:

    name:\"Stefan\",
    total:7.5,
    address:\"Sydney, AU\",
    deliveryDate:1314595427866,
    id:{
        shopCountry:\"AU\",
        shopCity:\"Sydney\",
        shopName:\"Pizza Pan 1\"
    },
    pizzas:[{id:8,version:1}]

I'm also trying to better understand the PizzaOrder Entity defined in pizzashop.roo:

entity jpa --class ~.domain.PizzaOrder --testAutomatically --activeRecord false --identifierType ~.domain.PizzaOrderPk
field string --fieldName name --notNull --sizeMin 2
field string --fieldName address --sizeMax 30
field number --fieldName total --type java.math.BigDecimal
field date --fieldName deliveryDate --type java.util.Date
field set --fieldName pizzas --type ~.domain.Pizza

field string --fieldName shopCountry --class ~.domain.PizzaOrderPk
field string --fieldName shopCity
field string --fieldName shopName

This was when I noticed the odd looking PizzaOrderPk class definition tacked onto the. shopCountry fieldname somehow. Is this legal roo syntax? If so, then what is it? Some sort of inner class? Or shouldn't the PizzaOrderPk class actually be defined as an Entity like other classes? This just seemed a little weird...

Dave - thanks for your effort on this. In fact this Jira is not affected by the failing curl statement as I described. This and previous curl statements did not work due to reasons I did not fully investigate when the team member who created the the json add-on, Stefan Schmidt, left VMware.
I'm resolving this now as complete ready for 1.2.4 release by end June '13
Any extra info in actually creating a pizzaorder using curl would be a bonus!
Alan