No way to discover the originating VirtualHost

[tliron]

As it stands, Restlet's routing mechanism leaves no trace of which VirtualHost handled the request. However, for applications that run on multiple hosts, it may be useful to alter their behavior according to which host a request came from.

My suggestion is that this could be done via a request attribute. Already the VirtualHost class attaches a filter to each request, so why not do it there? Here is my suggested addition (at NEW):

    @Override
    protected TemplateRoute createRoute(String uriPattern, Restlet target,
            int matchingMode) {
        TemplateRoute result = new TemplateRoute(this, uriPattern, target) {
            @Override
            protected int beforeHandle(Request request, Response response) {
                final int result = super.beforeHandle(request, response);

                // Set the request's root reference
                request.setRootRef(request.getResourceRef().getBaseRef());

                // NEW: Set the VirtualHost
                request.getAttributes().put("org.restlet.routing.VirtualHost", VirtualHost.this);

                // Save the hash code of the current host
                setCurrent(VirtualHost.this.hashCode());

                return result;
            }
        };

        result.getTemplate().setMatchingMode(matchingMode);
        result.setMatchingQuery(getDefaultMatchingQuery());
        return result;
    }

(Related comment: I don't know what setCurrent() and getCurrent() are used for, but they seem to be a bad idea, because they are set in the thread content. However, Restlet does now allow requests to be closed from other threads. Anything that relies on getCurrent() could well be broken.)

[jlouvel]

Thanks for the feed-back.

That is the purpose of the VirtualHost#getCurrent() to be able to find the matching host based on its store hash code. The idea is also to isolate the virtual host from the Restlet down the routing chain to prevent them.

But, I understand your concerns regarding the thread local and lack of accessibility when isolation isn't such a concern. We could revisit this design for V3.0 of the API.

[tliron]

Also, beyond the thread breakage, getCurrent() returns a hash code, which isn't very helpful.

There is a workaround: insert a filter before the attached application that does this. It's what I did for Prudence. However, this seems so essential and easy to fix, that I think it should be included in Restlet.

https://code.google.com/p/prudence/source/browse/components/prudence/source/com/threecrickets/prudence/util/VirtualHostInjector.java