Jetty

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

Ascending order - Click to sort in descending order
Hide
Permalink
Greg Wilkins added a comment -

I've reproduced this

Show
Greg Wilkins added a comment - I've reproduced this
Hide
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: