Re: Strange results trying Jetty 6 version of Http service

[Rob Walker]

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. -- Rob Rob Walker wrote: 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 102.4 of the R4 companion spec uses the following table to show mapping: We have a very similar example 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). -- Rob Rob Walker wrote: I haven't - will take a look if feasible. >From my earlier work in this area - I've a hunch this doesn't follow the spec! -- rob Stuart McCulloch wrote: 2008/10/10 Rob Walker <[EMAIL PROTECTED]>   Anyone else found strange results moving to the Jetty 6 version of Http? It totally breaks our implementation, and seems to be directing getResource() requests to odd (possibly wrong) resource handlers 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" This feels broken to me - a "general" alias shouldn't get routed to a context class with a specific qualifier on the end which doesn't match?     have you tried the same test with Pax-Web?  Alin spent a lot of time making sure it followed the spec.   Regards -- Rob Ascert - Taking systems to the Edge [EMAIL PROTECTED] +44 (0)20 7488 3470 www.ascert.com       -- Ascert - Taking systems to the Edge [EMAIL PROTECTED] +44 (0)20 7488 3470 www.ascert.com -- Ascert - Taking systems to the Edge [EMAIL PROTECTED] +44 (0)20 7488 3470 www.ascert.com