Jetty
  1. Jetty
  2. JETTY-1297

Class path of contexts mixed(?) when using / as context path

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 7.2.0
    • Fix Version/s: 7.2.1
    • Component/s: None
    • Labels:
      None
    • Environment:
      Ubuntu 10.04 using
      Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)
      or Oracle JRockit(R) (build R28.0.0-679-130297-1.6.0_17-20100312-2121-linux-x86_64, compiled mode)
    • Number of attachments :
      0

      Description

      This might be related to JETTY-1295.

      I have two contexts with contextPath=/ and different virtualHosts. Both are Grails web applications but with different versions. After starting the Jetty server one of the applications works fine, the other (that has been initialized as second) fails with a class cast exception "org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequest cannot be cast to org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequest". So it seems to me that the class paths of the two contexts get somehow "mixed".

      Unfortunately I found no simple test case for this issue. The war files are ~20MB each so I cannot attach them here. The easiest way to reproduce it is to create to applications with different Grails version (I used 1.3.4 and 1.3.5):
      ~/grails-1.3.4/bin/grails create-app app1; cd app1; ~/grails-1.3.4/bin/grails war
      ~/grails-1.3.5/bin/grails create-app app2; cd app2 ~/grails-1.3.5/bin/grails war
      Then I created context files for both war files with contextPath=/ and different virtualHosts.

        Activity

        Hide
        Greg Wilkins added a comment -

        I've reproduced this

        Show
        Greg Wilkins added a comment - I've reproduced this
        Hide
        Greg Wilkins added a comment -

        The problem is mostly the fault of Grails.

        It does a ServletContext.getContext("/") and then dispatches the request to it with request wrappers. But getContext is not virtual host aware, so it gives back the wrong context.

        I'm not sure if getContext should be virtual host aware, but failing the ability to be specific about multiple contexts, I guess it should give priority to same virtual hosts rather than any contexts with different virtual hosts.

        I will try a work around, but you may want to raise this issue with grails and see what they say.

        Show
        Greg Wilkins added a comment - The problem is mostly the fault of Grails. It does a ServletContext.getContext("/") and then dispatches the request to it with request wrappers. But getContext is not virtual host aware, so it gives back the wrong context. I'm not sure if getContext should be virtual host aware, but failing the ability to be specific about multiple contexts, I guess it should give priority to same virtual hosts rather than any contexts with different virtual hosts. I will try a work around, but you may want to raise this issue with grails and see what they say.
        Hide
        Greg Wilkins added a comment -

        I've fixed this by making getContext handle the case where there are multiple matching contexts. If the current context matches, then it is returned. Otherwise the context lists is scanned for the first one with a matching virtual host.

        Show
        Greg Wilkins added a comment - I've fixed this by making getContext handle the case where there are multiple matching contexts. If the current context matches, then it is returned. Otherwise the context lists is scanned for the first one with a matching virtual host.

          People

          • Assignee:
            Greg Wilkins
            Reporter:
            Jesper Zedlitz
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: