felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-763) Jetty6 version of Http doesn't resolve aliases according to OSGi spec
Date Mon, 13 Oct 2008 06:08:44 GMT

    [ https://issues.apache.org/jira/browse/FELIX-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638948#action_12638948
] 

Niclas Hedhman commented on FELIX-763:
--------------------------------------

AFAIR, not Jetty 4 nor Jetty 5 did it any differently. The described problem has been in the
org.ungoverned codebase since we first used it 2-3 years ago. The scary part is that the TCK
doesn't test this, and a few other spec bits where org.ungoverned doesn't fully comply (can't
recall what it was).

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


Mime
View raw message