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 <ro...@ascert.com> on 2008/10/13 15:18:46 UTC

Http service Heads up - possible breaking change - FELIX-763

Just a heads-up that I'll be checking some mods in for this shortly that 
*may* break existing apps using the Felix Http service.

The current implementation definitely wasn't resolving aliases 
correctly. I'm reasonably confident I've got it a fair bit closer, but 
it's probably still not quite perfect.

Even with these fixes, we had to make a few mods to our application to 
make it work with the new Jetty6 based service. However, in most cases 
the mods we were left with were "questionable" cases in our code where 
it's possible we were relying on "less than standard" features of the 
Felix service. Just some examples:

    * we suddenly started getting GWT classloading errors - but reading
      around, it seems others get these anyhow under OSGi, so I suspect
      some previous quirk got around them for us:

    http://wiki.eclipse.org/Google_Web_Toolkit_and_Equinox

    We solved it with an intercept subclass (RemoteServiceServlet)
    between our servlets and GWT - which forces the context classloader
    for every service request.

    * We originally registered /VtWebUi as an alias - and when we served
      up our starting page of /VtWebUi/VtWebUi.html from this alias,
      subsequent resource requests for relative URL's in the html page
      worked fine. It seems now that these get a Referer URL but the
      relative links are missing the initial /VtWebUi needing for alias
      resolution.

    In a strange way this makes sense - the registerResource is saying that

        * "/VtWebUi"  paths should map to "/"

    So any resource returned from this has a relative base path of "/" -
    so enclosed resource URLs in the returned HTML, are being seen as
    relative to "/" rather than the alias. I'm not totally sure if this
    is broken or is actually correct - will carry on investigating to
    see if there is an underlying solution needed. For now - the
    workaround for us was to serve our "starting page" from the full URL
    e.g.

    /VtWebUi/VtWebUi.html 

I'll leave this issue open for a few weeks until others have had a 
chance to use it and send feedback.

BTW - I totally agree with Niclas's earlier comment about lacking a TCK 
that makes this area 100% clear and verifiable. For example:

    * Sec 102.4 of the spec has a bullet point (2) saying that an alias
      of "/" should be resolved by using the internal name with the URL
      appended
    * The example a little further on in Table 6 - row 3 though doesn't
      follow this - it would be /tmp/fudd/bugs if it followed the spec
      statement above (and would make a lot more sense!)


Oh - btw - I also updated the POM to get the latest 6.1.12.rc3 version 
of Jetty.

Regards

-- Rob


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com