dev@jersey.java.net

URI resolving going forward

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 05 Oct 2007 16:12:57 +0200

Hi,

Below are the proposed steps going forward for URI path resolving:

1) Change URI path resolving to work from a simple regular expression
    model (generated from a URI template or otherwise). This is so we can
    fix issue 1 [1] and can easily support distinct URIs with suffixes
    associated with media type, language etc that we have been discussing
    in the EG.

2) Integrate the automaton (trie) resolver into the trunk (keeping the
    linear resolver in the trunk too for backup, perhaps we should have a
    runtime option on which to use?) and ensure it works with changes
    introduced for 1).

3) Change URI path resolving to the same model as Phobos. I have been
    talking with Roberto (the Phobos guy) and he convinced me that the
    model Phobos uses is more flexible than what Jersey currently has and
    should result in more simplicity when we need to add more features.
    Basically Phobos has a list of rules, each rule contains a regular
    expression and an accepting function. The basic algorithm is as
    follows:

    for rule in rules:
      if rule.regexp.match(url) and rule.accept(url):
        break

    So a match is just the first stage from which the rule can decide
    whether it accepts the match or whether matching should continue.

    This allows us to have the following rules associated with a resource
    class:

    - a head rule to dynamically detect view templates (like JSPs or
      Velocity templates) for a resource class that are not explicitly
      declared on the resource class. Same goes for static content;

    - two resource classes with the same URIs but supporting different
      representations e.g. implement XML then implement Atom without
      changing existing code. The first could return a not acceptable
      response and therefore it is a non-accepting rule and it passes it
      over to the next one; and

    - return a customized 404 response. A tail rule could return a
      particular 404 response (or any other error-based response) for a
      resource class.


    To ensure existing code works we can integrate the UriPathResolver as
    one rule. That way the trie algorithm will still work and then we
    can think how to transition it over to a more general rule based
    implementation.


Sound like a plan? Any opinions either way on this approach?

Paul.

[1] https://jersey.dev.java.net/issues/show_bug.cgi?id=1

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109