[jira] Resolved: (FELIX-763) Jetty6 version of Http doesn't resolve aliases according to OSGi spec

["Rob Walker (JIRA)" <ji...@apache.org>]

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

Rob Walker resolved FELIX-763.
------------------------------

    Resolution: Fixed

Have marked as "resolved" for now.

Managed with a relatively small number of changes to get Jetty mapping paths to aliases in a way that looks much closer to the spec so far. Certainly for our examples here, it's much more according to spec.

Changes comitted to SVN - will leave a few weeks before feedback before closing the issue.

> 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.