A Cup of Silverlight, RIA & Interoperability : Tip

Tip : Add XAP Mime-Type in Tomcat and IIS 5.1

Steve SFARTZ — Thu, 28 Aug 2008 12:00:00 GMT

Mime-Type are used to provide identifiers for file formats on the Internet.

By default, XAP files are not recognized as a Silverlight application in Tomcat or IIS 5.1. You can set a Mime-Type to identify XAP files on both servers.

Setting Mime-Type in Tomcat

in %TOMCAT_INSTALL%/conf directory, edit web.xml file. Add the following description to identify XAP files

<mime-mapping>

    <extension>xap</extension>

    <mime-type>application/x-silverlight-2-b2</mime-type>

</mime-mapping>

Restart Tomcat and clear your navigator cache,
get a XAP file to ensure that the Mime-Type is correctly set

Setting Mime-Type in IIS 5.1

Open the IIS Management Console
Open your Web Site properties, under HTTP Headers click on File Types button

In the File Types window, click New Type to add a new Mime-Type

Get a XAP file within IIS to ensure that the Mime-Type is correctly set

- Ronny Kwon

Tip : Serving JSPs and Servlets from IIS through Tomcat

Steve SFARTZ — Tue, 12 Aug 2008 17:21:00 GMT

This tip is about making IIS as a front end to Tomcat hosting Servlets and JSPs on the back end. This architecture allows the hosting of JAX-WS or Restlet services in Tomcat while Silverlight clients are hosted in IIS without facing cross-domain issues.

The configuration files and the connector (isapi_redirect.dll) are available as an attachment to this post. Before continuing, you must download the Zip archive and unzip it to C:\Program Files\Apache Software Foundation

The following is inspired from

The Apache Tomcat Connector - Webserver HowTo : IIS HowTo

Pre-requisites

From this point, we assume that

IIS 5.1 is installed on a Windows XP SP2 Professional Edition
Apache Tomcat 6.0.16 is installed and working properly on the same OS

The Tomcat installation directory is C:\Program Files\Apache Software Foundation\Apache Tomcat 6.0.16

You have unzipped the archive, you must have the following directory : C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector

Configuring the ISAPI Redirector

Open the Registry Editor, Run—>regedit

Create a new registry key names “HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0”

The following screenshot shows you the different values you have to create in the previous created key

name	value
extension_uri	/jakarta/isapi_redirect.dll
log_file	C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\log\isapi_redirect.log
log_level	info
worker_file	C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf\workers.properties.minimal
worker_mount_file	C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf\uriworkermap.properties

Open the IIS Management Console
add a new Virtual Directory to the Default Web Site

Alias must be set to “jakarta”
Directory must be set to isapi_redirector.dll location C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\bin
Allow Execute permission

Now let’s add a new ISAPI filter

open the properties dialog of the Default Web Site, in the ISAPI Filters tab, click add to add a new filter.
Set the filter name to “jakarta”
Executable is the exact location of the isapi_redirect.dll : C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\bin\isapi_redirect.dll
Restart the IIS Server then check for the jakarta filter, an up-green arrow has appeared

Also start Tomcat server.

In a Web Browser, ensure that http://localhost:8080/examples/jsp/index.html is accessible :

It’s normal, this page is served by Tomcat (assuming that it is running on port 8080)

Now access to this page within IIS (in our case, we set IIS port to 81), by default port 80 is used.

Go to http://localhost:81/examples/jsp/index.html. A similar page is displayed.

Try to execute a jsp example :

Configuring the URL mapping

In the C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf directory you will find two configuration files :

workers.properties.minimal : it describes the host(s) and port(s) used by Tomcat processes.
uriworkermap.properties : it maps URL-Path patterns to workers

In the uriworkermap.properties you will find the mapping of URL to be handled by the workers declared in workers.properties. An example of URL mapping:

default.worker=ajp13

/docs=$(default.worker)
/docs/*=$(default.worker)
/examples=$(default.worker)
/examples/*=$(default.worker)
/host-manager=$(default.worker)
/host-manager/*=$(default.worker)
/manager=$(default.worker)
/manager/*=$(default.worker)

In this configuration, every request on /examples/* will be handled by the Tomcat process, that’s how we managed to serve JSPs and Servlets from IIS through Tomcat. You may add your own URL patterns... if you do so, don’t forget to restart the Tomcat Server.

- Ronny Kwon

Tip : Cross Domain Policy when Self-Hosting your Services

Steve SFARTZ — Mon, 11 Aug 2008 15:24:00 GMT

This tip is about self hosting of services with the .Net WCF or Java Restlet framework. Cross-domain access is mandatory here since the Site of Origin does not host the services.

Self hosting a service represents a quick & easy way to expose a Web Service for tests purpose. Yet, customization is extermely limited since self hosting does not provide you all the capabilities of Web Servers such as delivering static content (cross domain policy file).

The first thing you need to know is that when Silverlight attempts to access services in cross-domain, it will send a HTTP GET method on http://<domain:port>/clientaccesspolicy.xml or http://<domain:port>/crossdomain.xml (in case clientaccesspolicy.xml wasn’t found). If you plan to self host your Web Service, you will agree that there is no possible way to host a physical Cross Domain policy file at the root of the Web Server.

You must handle this request through your Service implementation. It usually matches the /clientaccesspolicy.xml or /crossdomain.xml URI pattern.

WCF way (inspired from Carlo’s blog)

Self-hosted Service

class Program

    static void Main(string[] args)

        // URI of the Service

        Uri uri = new Uri("http://localhost:8081/");

        // create a new WebServiceHost specifying the implementation of the Service

        // and the specified uri to bind with

        WebServiceHost host = new WebServiceHost(

                new REST_ItemsServiceLibrary.ItemsREST(),

                uri);

        // add the Service Endpoint specifying the Service Interface

        host.AddServiceEndpoint(typeof(REST_ItemsServiceLibrary.IItemsREST),

                                new WebHttpBinding(), "");

        // open the WebServiceHost

        host.Open();

        Console.WriteLine("Service hosted at {0}", uri.OriginalString);

        Console.ReadLine();

        // close the WebServiceHost

        host.Close();

Handling cross-domain file requests

As we said earlier, we have to manage the /clientaccesspolicy.xml, specify in the Service Interface that HTTP GET method on the URI /clientaccesspolicy.xml will be handled by GetSilverlightPolicy();

[OperationContract]

[WebGet(UriTemplate ="/clientaccesspolicy.xml")]

Stream GetSilverlightPolicy();

this also applies to /crossdomain.xml

Finally, in your Service implementation, return a clientaccesspolicy.xml content:

public Stream GetSilverlightPolicy()

    string result = @"<?xml version=""1.0"" encoding=""utf-8""?>

<access-policy>

    <cross-domain-access>

        <policy>

            <allow-from http-request-headers=""*"">

                <domain uri=""*""/>

            </allow-from>

            <grant-to>

                <resource path=""/"" include-subpaths=""true""/>

            </grant-to>

        </policy>

    </cross-domain-access>

</access-policy>";

    return StringToStream(result);

Stream StringToStream(string result)

    WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";

    return new MemoryStream(Encoding.UTF8.GetBytes(result));

Restlet way

Self-hosted Service

public static void main(String[] args) {

    try {

        // Create a new Component.

        Component component = new Component();

        // Add a new HTTP server listening on port 8182.

        component.getServers().add(Protocol.HTTP, 8182);

        // Attach the sample application.

        component.getDefaultHost().attach(

                new FirstResourceApplication(component.getContext()));

        // Start the component.

        component.start();

    } catch (Exception e) {

        // Something is wrong.

        e.printStackTrace();

Handling cross-domain file requests

Following the same philosophy as the WCF way, we need to handle HTTP GET method on /clientaccesspolicy.xml file request :

In the Application implementation you must bind the URI pattern with the Ressource that will handle it :

Finally, implement the ClientAccessPolicy class, specially the HTTP GET method within getRepresentation method :

package firstResource;

import java.io.IOException;

import org.restlet.Context;

import org.restlet.data.MediaType;

import org.restlet.data.Request;

import org.restlet.data.Response;

import org.restlet.resource.DomRepresentation;

import org.restlet.resource.Representation;

import org.restlet.resource.Resource;

import org.restlet.resource.Variant;

import org.w3c.dom.Document;

import org.w3c.dom.Element;

public class ClientAccessPolicy extends Resource{

    public ClientAccessPolicy(Context context, Request request,

            Response response) {

        super(context, request, response);

        getVariants().add(new Variant(MediaType.TEXT_XML));

    @Override

    public Representation getRepresentation(Variant variant){

        if (MediaType.TEXT_XML.equals(variant.getMediaType())) {

             try {

                DomRepresentation representation = new DomRepresentation(

                      MediaType.TEXT_XML);

                // Generate a DOM document representing the list of

                // items.

                Document d = representation.getDocument();

                Element accesspolicy = d.createElement("access-policy");

                d.appendChild(accesspolicy);

                Element crossdomainaccess = d.createElement("cross-domain-access");

                accesspolicy.appendChild(crossdomainaccess);

                Element policy = d.createElement("policy");

                crossdomainaccess.appendChild(policy);

                Element allowfrom = d.createElement("allow-from");

                allowfrom.setAttribute("http-request-headers","*");

                Element domain = d.createElement("domain");

                domain.setAttribute("uri", "*");

                allowfrom.appendChild(domain);

                Element grantto = d.createElement("grant-to");

                Element resource = d.createElement("resource");

                resource.setAttribute("include-subpaths","true");

                resource.setAttribute("path", "/");

                grantto.appendChild(resource);

                policy.appendChild(allowfrom);

                policy.appendChild(grantto);

                d.normalizeDocument();

                // Returns the XML representation of this document.

                return representation;

             } catch (IOException e) {

                e.printStackTrace();

          return null;

- Ronny Kwon