OpenRasta: Uri seems to be irrelevant for handler selection

Question

When registering two handlers for the same type, but with different URIs, the handler selection algorithm doesn't seem to check the uri when it determines which handler to use.

If you run the program below, you'll notice that only HandlerOne will be invoked (twice). It does not matter if I call for "/one" or "/two", the latter supposed to be handled by HandlerTwo.

Am I doing something wrong or is this something to be fixed in OpenRasta? (I'm using 2.0.3.0 btw)

class Program
{
    static void Main(string[] args)
    {
        using (InMemoryHost host = new InMemoryHost(new Configuration()))
        {
            host.ProcessRequest(new InMemoryRequest
            {
                HttpMethod = "GET",
                Uri = new Uri("http://x/one")
            });
            host.ProcessRequest(new InMemoryRequest
            {
                HttpMethod = "GET",
                Uri = new Uri("http://x/two")
            });
        }
    }
}
class Configuration : IConfigurationSource
{
    public void Configure()
    {
        using (OpenRastaConfiguration.Manual)
        {
            ResourceSpace.Has.ResourcesOfType(typeof(object))
                .AtUri("/one").HandledBy(typeof(HandlerOne));
            ResourceSpace.Has.ResourcesOfType(typeof(object))
                .AtUri("/two").HandledBy(typeof(HandlerTwo));
        }
    }
}
class HandlerOne
{
    public object Get() { return "returned from HandlerOne.Get"; }
}
class HandlerTwo
{
    public object Get() { return "returned from HandlerTwo.Get"; }
}

Update I have a feeling that I could accomplish what I want similar using UriNameHandlerMethodSelector as described on http://trac.caffeine-it.com/openrasta/wiki/Doc/Handlers/MethodSelection, but then I'd have to annotate each handler methods and also do AtUri().Named(), which looks like boilerplate to me and I'd like to avoid that. Isn't AtUri(X).HandledBy(Y) making the connection between X and Y clear?

Answer 1

Eugene,

You should never have multiple registrations like that on the same resource type, and you probably never need to have ResourcesOfType<object> ever associated with URIs, that'll completely screw with the resolution algorithms used in OpenRasta.

If you're mapping two different things, create two resource classes. Handlers and URIs are only associate by resource class, and if you fail at designing your resources OpenRasta will not be able to match the two, and this is by design.

If you want to persist down that route, and I really don't think you should, then you can register various URIs to have a name, and hint on each of your methods that the name ought to be handled using HttpOperation(ForUriName=blah). That piece of functionality is only there for those very, very rare scenarios where you do need to opt-out of the automatic method resolution.

Finally, as OpenRasta is a compsable framework, you shouldnt have to go and hack around existing classes, you ought to plug yourself into the framework to ensure you override the components you don't want and replace them by things you code yourself. In this case, you could simply write a contributor that replaces the handler selection with your own moel if you don't like the defaults and want an MVC-style selection system. Alternatively, if you want certain methods to be selected rather than others, you can remove the existing operation selectors and replace them (or complement them with) your own. That way you will rely on published APIs to extend OpenRasta and your code won't be broken in the future. I can't give that guarantee if you forked and hacked existing code.

Answer 2

As Seb explained, when you register multiple handlers with the same resource type OpenRasta treats the handlers as one large concatenated class. It therefore guesses (best way to describe it) which potential GET (or other HTTP verb) method to execute, which ever it thinks is most appropriate. This isn't going to be acceptable from the developers prospective and must be resolved.

I have in my use of OpenRasta needed to be able to register the same resource type with multiple handlers. When retrieving data from a well normalised relational database you are bound to get the same type response from multiple requests. This happens when creating multiple queries (in Linq) to retrieve data from either side of the one-to-many relation, which of course is important to the whole structure of the database.

Taking advice from Seb, and hoping I've implemented his suggestion correctly, I have taken the database model class, and built a derived class from it in a resources namespace for each instance of when a duplicating resource type might have been introduced.

ResourceSpace.Has.ResourcesOfType<IList<Client>>()
                .AtUri("/clients").And
                .AtUri("/client/{clientid}").HandledBy<ClientsHandler>().AsJsonDataContract();

ResourceSpace.Has.ResourcesOfType<IList<AgencyClient>>()
                .AtUri("/agencyclients").And
                .AtUri("/agencyclients/{agencyid}").HandledBy<AgencyClientsHandler>().AsJsonDataContract();

Client is my Model class which I have then derived AgencyClient from.

namespace ProductName.Resources
{
    public class AgencyClient: Client { }
}

You don't even need to cast the base class received from your Linq-SQL data access layer into your derived class. The Linq cast method isn't intended for that kind of thing anyway, and although this code will compile it is WRONG and you will receive a runtime exception 'LINQ to Entities only supports casting Entity Data Model primitive types.'

Context.Set<Client>().Cast<AgencyClient>().ToList();  //will receive a runtime error

More conventional casts like (AgencyClient) won't work as conversion to a SubClass isn't easily possible in C#. Convert base class to derived class

Using the AS operator will again compile and will even run, but will give a null value in the returned lists and therefore won't retrieve the data intended.

Context.Set<Client>().ToList() as IEnumerable<AgencyClient>; //will compile and run but will return null

I still don't understand how OpenRasta handles the differing return class from the handler to the ResourceType but it does, so let's take advantage of it. Perhaps Seb might be able to elaborate?

OpenRasta therefore treats these classes separately and the right handler methods are executed for the URIs.

Answer 3

I patched OpenRasta to make it work. These are the files I touched:

OpenRasta/Configuration/MetaModel/Handlers/HandlerMetaModelHandler.cs
OpenRasta/Handlers/HandlerRepository.cs
OpenRasta/Handlers/IHandlerRepository.cs
OpenRasta/Pipeline/Contributors/HandlerResolverContributor.cs

The main change is that now the handler repository gets the registered URIs in the initializing call to AddResourceHandler, so when GetHandlerTypesFor is called later on during handler selection, it can also check the URI. Interface-wise, I changed this:

public interface IHandlerRepository
{
    void AddResourceHandler(object resourceKey, IType handlerType);
    IEnumerable<IType> GetHandlerTypesFor(object resourceKey);

to that:

public interface IHandlerRepository
{
    void AddResourceHandler(object resourceKey, IList<UriModel> resourceUris, IType handlerType);
    IEnumerable<IType> GetHandlerTypesFor(object resourceKey, UriRegistration selectedResource);

I'll omit the implementation for brevity.

This change also means that OpenRasta won't waste time on further checking of handlers (their method signatures etc.) that are not relevant to the request at hand.

I'd still like to get other opinions on this issue, if possible. Maybe I just missed something.