How to host Silverlight (.xap) on Google App Engine with Java SDK

...or any other file with a MIME-type that Google App Engine does not treat nice by default.

Problem: Lack of control over MIME-types and static files on Google App Engine

Apparently, it is not possible to host a .xap file as a static file on Google App and register a correct MIME-type for it. If you search around, you might find hints that it is possible to do with the Python SDK (configuring handlers), but you might also find people can't get the MIME-settings to work with the Java SDK. Recently, I was one of the later, so here is a solution for you that hopefully will save you some time.

Solution: Create a servlet that loads the .xap file as a resource and streams it to the client

This part might sound complex but really is simple. Here are the steps to get it working, though you might need to refine it for production:

1) Produce your .xap file, test .html file and silverlight.js file and copy those into your war folder. Here is my test example structure in an Eclipse project:

2) Create a HttpServlet-extending Java class file (that I named NaiveFileServlet.java) with content similar to the following:

3) Register .xap files as a servlet resource in appengine-web.xml:

4) Register your servlet and URL-patterns in file web.xml:

5) Deploy your app as you normally do, visit the test .html page and enjoy your Silverlight app.

Here is a running example: http://yoaws-slogaet.appspot.com/ (click and move your mouse).

OnTime for Scrum? Step#1 - Customization

The Scrum Master and the Product Owner customizes.
A simulation of a Scrum team using OnTime...

Background
Per Owen once asked himself: "Is that OnTime software really any good for doing Scrum?".
To figure out an answer to this question, he went to management and got himself 1) a new project to work on, and 2) a role as the project's Product Owner.

Management is wise, so they also assigned this evaluation project their newly educated Scrum Master, Sara Mart, and 2 Team Members: Tim Mee & Tom Bert. In this way they would get to evaluate OnTime as a tool to be used within a project using the Scrum framework.

The Scrum Master customizing OnTime
Sara Mart eagerly downloaded OnTime 2009 from http://www.axosoft.com/.
Apart from the usual SQL Server configuration querks, she soon had the OnTime Windows client application starting up. Sara usually felt more productive with an OS native application, though she acknowledged that the OnTime web application could come in handy at some point in time... for some.

Defects, Features, Tasks and Incidents?
The first puzzle to solve for Sara was to get the Scrum terminology into OnTime. Her first impression of OnTime was that it focuses on management of 4 primary data list: Defects, Features, Tasks and Incidents. Fortunately, the names of these list can be customized, so she changed them to: Product Bugs, Product Backlog, Sprint Backlog and Impediment List.

Although the Product Bugs might not be a Scrum artifact, Sara thought it would be nice, if a bug could be pulled into a sprint just like a user story can be pulled from the Product Backlog.

Project Wiki and Roles?

Sara also embraced the Project Wiki page, since this could show to be a nice communcation mean for the team. She created a project page listing the project members, which reminded her of creating them as OnTime users. This task was simple to do and to her surprise OnTime has Scrum roles that can be associated with a user.

Thats it, Sara thought, and she went to see Per Owen, so they could try populating the Product Backlog together.

The Scrum Master and Product Owner customizing the Product Backlog
Per Owen had just finished installing OnTime when a very positive Sara entered his office. He was soon logged in and updated about the changes Sara had made.
They had just begun looking at the data list now named Product Backlog, when Per heard the words: "Oh no, this ain't going to work".

The default Product Backlog view needs nursing
Unfortunately, Per was the owner of this statement, so he now owned Sara (and himself) an explanation. Per explained to Sara (and himself) that the default setup of the Product Backlog was not really what he wanted. A little hour later this minor setback was turned into a positive experience for both Sara and Per.


Per user changes
As the Product Owner and a new OnTime user, Per didn't want too much information to begin with, so Sara helped him disabling all other views but the Project Wiki and the Product Backlog.
Furthermore, Per would like a little more clean Product Backlog view, so they disabled the Assigned To column, enabled the Original Estimate column, and made the following system wide changes.

Per system changes
In OnTime all data fields are associated with a field label that an administer can change, so Sara logged in and changed 'Feature Id' to 'Story Id'.

Per needed to be able to value each story in terms of business value, that is, how much worth a released story would become. OnTime didn't really have a column that could be used to represent this. Priority couldn't really be it, since more complex things like dependencies, resources and external opinions affects priority.
After some searching around, Sara and Per settled on creating a new system wide custom field; an integer called 'Business Value'.

Product Stories Workflow Template
The workflow column in the Product Backlog is an optional state management tool that Sara and Per agreed on trying out. Obviously, the default workflow template didn't match Per's needs, so they decided to make a new template one.

Per would like everyone to add new stories to the Product Backlog, so they created a 1st step name New and configured OnTime such that all could create a new story and it would be marked as New by default.
2nd step they called Valued meaning that the Product Owner, Per, would value the new story. 3rd step they called Estimated and made the team (Developer role) responsible for getting a story into this state. 4th step they called Prioritized, since that would be Per and Sara weighting business value, estimates and what not for each story, and assigning a priority. 5th step they called In Production meaning commited to a sprint by the team and Sara.

A 6th step would be one of the the possible outcomes for a story in production: Released (in working software at end of sprint), Descoped (not released at end of sprint) and Aborted (not released since sprint was aborted).
In OnTime each state can associated with a next allowed state, so Sara and Per specified state progresion for stories as a simple state graf 1->2->3->4->5->(6|7->2|8->2) with an outer loop for Descoped and Aborted.