You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Rob Walker (JIRA)" <ji...@apache.org> on 2008/10/13 07:50:44 UTC
[jira] Created: (FELIX-763) Jetty6 version of Http doesn't resolve
aliases according to OSGi spec
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.
[jira] Resolved: (FELIX-763) Jetty6 version of Http doesn't resolve
aliases according to OSGi spec
Posted by "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.
[jira] Assigned: (FELIX-763) Jetty6 version of Http doesn't resolve
aliases according to OSGi spec
Posted by "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 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.
[jira] Commented: (FELIX-763) Jetty6 version of Http doesn't
resolve aliases according to OSGi spec
Posted by "Rob Walker (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638953#action_12638953 ]
Rob Walker commented on FELIX-763:
----------------------------------
Agree that the earlier Jetty4 version didn't fully follow spec, but this is a new error case - our original code worked fine against the Jetty4 version and now totally breaks under the above. The Jetty4 version definitely didn't send getResource requests to aliases that didn't match the base path, at least not for the codebase / examples we have here.
Totally agree that it'd be nice if a TCK of some form existed to verify this specific part.
> 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.
[jira] Commented: (FELIX-763) Jetty6 version of Http doesn't
resolve aliases according to OSGi spec
Posted by "Niclas Hedhman (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Work started: (FELIX-763) Jetty6 version of Http doesn't
resolve aliases according to OSGi spec
Posted by "Rob Walker (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on FELIX-763 started by 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.