Original Source

Colin Harrington writes about enabling a crossdomain.xml file with Grail’s embedded Jetty server. Anybody working on highly interactive web sites knows about crossdomain.xml, often times related to Flash/Flex, but in Colin’s case he actually desired to demonstrate that Microsoft’s Silverlight was able to communicate with non Microsoft technologies.

This last April I did a presentation at the Twin Cities Code Camp on Microsoft Silverlight and SOA with a Grails server.  I ended up writing a simple Grails application that used several web services to communicate to an in-browser Silverlight application.  I specifically wanted to show a Silverlight application interacting with non Microsoft Technologies.  I developed the Grails application on Linux on a different physical machine than what I used to develop the Silverlight application.

One of the Issues I ran into was that I was unable to make requests to the XML Web Services in the Grails application.  It puzzled me for a minute until a quick Google search turned up a simple issue: I needed a crossdomain.xml policy file (or the clientaccesspolicy.xml).  Flash/Flex users run into this all the time and thus most of what you will find is Flash centric.  What is the crossdomain.xml file?  Well its a way of restricting the domains that can access services.  Its basically a white-listing of domains that are allowed to access the services.  The browser and in-browser applications are supposed to respect the crossdomain.xml, and sometimes the Services (server-side) may protect themselves.  You can think of it as a robots.txt for Web services.

Great, I knew what the problem was, now how do I fix it?  I tried a few things, deploying to tomcat, but that didn’t work for me while I was actively developing the application.  Once I understood a little more about Grails and Jetty, I realized that I could just modify the Jetty server that launched when invoking grails run-app.  I simply had to add another context to Jetty, and bingo it worked.

The second context is actually a parallel context to ${grails_app}/webapp, he chose ${grails_app}/webb-app-root (replace ${grails_app} with the name of your app). He then proceeded to hack $GRAILS_HOME/scripts/RunApp.groovy so that the parallel context was registered after the default one (inside the configureHttpServer target). The last step is to place the crossdomain.xml file inside the parallel context.

The technique demonstrated by Colin will only work for Grail’s embedded Jetty server, and as he notes, there may be a better way to do it. Regardless of that, if you need to test/communicate with RIA based technologies and a crossdomain.xml file is required, then this technique is a quick fix to get you going.

Tags: Colin Harrington, Grails