You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Niclas Hedhman (JIRA)" <ji...@apache.org> on 2008/10/13 08:08:44 UTC
[jira] Commented: (FELIX-763) Jetty6 version of Http doesn't
resolve aliases according to OSGi spec
[ 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.