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.
