Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <868477522.1223898767769.JavaMail.jira@brutus>
Date: Mon, 13 Oct 2008 04:52:47 -0700 (PDT)
From: "Rob Walker (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Assigned: (FELIX-763) Jetty6 version of Http doesn't resolve
 aliases according to OSGi spec
In-Reply-To: <1412880964.1223877044212.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/FELIX-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Walker reassigned FELIX-763:
--------------------------------

    Assignee: Rob Walker

> Jetty6 version of Http doesn't resolve aliases according to OSGi spec
> ---------------------------------------------------------------------
>
>                 Key: FELIX-763
>                 URL: https://issues.apache.org/jira/browse/FELIX-763
>             Project: Felix
>          Issue Type: Bug
>          Components: HTTP Service
>            Reporter: Rob Walker
>            Assignee: Rob Walker
>
> We have both of the following aliases mounted for resource serving:
>   * /VtWebUi - served by a "WebUiContext" class
>   * /VtWebUi/logs - served by a "LogsContext" class
> A request to
>   http://localhost:8084/VtWebUi
> is getting directed to the LogsContext class (which serves /VtWebUi/logs) -
> and the attached resource path is empty
> According to my understanding (and the previous Jetty 4 version) - this
> should get directed to the "WebUiContext" 
> ====
> Form further analysis:
> This looks definitely wrong to me in the current SVN rev, albeit our usage is a strange case that perhaps not many use, I think the new internal operation is wrong
> We have a very similar example to the table in 102.4 of the R4 companion spec. 
> alias 1 - /VtWebUi
> alias 2 - /VtWebUi/logs
> To me - a request for /VtWebUi - should only get routed to the getResource of alias 1?
> I can't see any way according to the spec, the getResource of alias 2 should be called - it's not a matching substring, even if the getResource for alias 1 returned null (which it wouldn't in our case anyhow).
> ===
> Additional info:
> Hmmm - some further clues that something may be amiss here:
>          //fails:
>          //srvHttp.registerResources(alias, "", myContext);
>          //srvHttp.registerResources(alias + logsAlias, "", this.envLogsContext);
>          //works:
>          srvHttp.registerResources(alias + logsAlias, "", this.envLogsContext);
>          srvHttp.registerResources(alias, "", myContext);
> Simply swapping the order of registration changes the behaviour , not quite to fully working - but a lot closer.
> I'm fairly sure the order of registration shouldn't change any behaviour, except in the case of a duplicate alias exception - which this isn't. The OSGi rules for walking back down a substring of aliases until there's a match aren't based on which got registered first
> Looking at the traces, Jetty seems to be using later registered aliases first - hence why the swap makes a difference. I suspect what is broken here is how Jetty does path matching to servlets - it doesn't look like it matches according to alias rules for OSGi in this newer Jetty version.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.