"appcfg.cmd stage" doesn't faithfully translate appengine-web.xml to app.yaml

[GoogleCodeExporter]

appengine-java-sdk-1.9.31

"appcfg.cmd stage" has been part of my deployment routine for my Java module.  
I noticed that the <threadsafe>false</threadsafe> tag in appengine-web.xml was 
not making into the app.yaml.  

Original issue reported on code.google.com by b...@unitydynamics.com on 31 Jan 2016 at 2:21

[GoogleCodeExporter]

Thanks for the report! I've opened an internal issue to track this.

Original comment by dlor...@google.com on 1 Feb 2016 at 4:36

[GoogleCodeExporter]

I think it does and supports the default value when not present, which is false

So the absence of it in app.yaml is treated as false. The staging phase omits 
the default value.
When true in xml, it is also correctly generated as true in the yaml file.

Original comment by l...@google.com on 1 Feb 2016 at 4:46

[GoogleCodeExporter]

So to my chagrin there is perhaps more to the story.  My module is a Managed VM 
app engine module.  It seems Managed VMs cannot run threadsafe: False.  I tried 
to add it manually post the "stage" command and deploy to App Engine: it didn't 
work.  Queue items hit the servlet concurrently.  Appreciate if someone else 
can confirm... I may need to change this into a feature request ticket.

Original comment by b...@unitydynamics.com on 1 Feb 2016 at 5:10

[GoogleCodeExporter]

I have an internal Google ticket out to verify that Managed VM instances cannot 
run in "threadsafe: false" (or False) mode.  "New Case Comment: [#08516190] 
Managed VM and "Threadsafe" setting."  If this setting isn't supported then I 
think it's incumbent on the "stage" command to report to the user that their 
desired behavior will not be respected on App Engine.  

When stage encounters vm=true and threadsafe=false in appengine-xml I suggest: 
"This Managed VM module deployment will ignore the 
<threadsafe>false</threadsafe> setting.  This behavior is not supported in the 
current version of Managed VMs."

Silently removing the flag (even if it's the default value) leaves no "line of 
defense" for the user understanding why their module isn't behaving as 
expected.  Concurrency issues can be tricky.  

Also note: threadsafe=true has been the default for us Java developers for many 
years!  If "stage" is going to remove explicit settings when they are default 
then I suggest we document those defaults plainly and comprehensively 
somewhere...

Original comment by b...@unitydynamics.com on 2 Feb 2016 at 6:20

[GoogleCodeExporter]

Alternative message: "You FOOL!  You've spent *hours* building code with the 
wrong concurrency model in mind.  I hope your Starbucks card is full."

Original comment by b...@unitydynamics.com on 2 Feb 2016 at 6:23

[GoogleCodeExporter]

Just a quick note... my finding was verified... Managed VMs *in Java* don't 
respect threadsafe: False.  So "stage" is doing it's job just fine... I suggest 
we close this issue (bad title).  The potential feature request of adding the 
status message might save someone else down the road a headache.  

Original comment by b...@unitydynamics.com on 7 Feb 2016 at 3:11