felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Walker (JIRA)" <j...@apache.org>
Subject [jira] Created: (FELIX-763) Jetty6 version of Http doesn't resolve aliases according to OSGi spec
Date Mon, 13 Oct 2008 05:50:44 GMT
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


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:

         //srvHttp.registerResources(alias, "", myContext);
         //srvHttp.registerResources(alias + logsAlias, "", this.envLogsContext);

         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.

View raw message