Grails

GrailsUrlMappingsTestCase broken for mappings to views

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.1
  • Fix Version/s: 2.0-M1
  • Component/s: Testing
  • Labels:
    None
  • Environment:
    Grails 1.1, java version "1.5.0_16", MacOSX
  • Testcase included:
    yes

Description

The GrailsUrlMappingsTestCase.assertView seems to be broken, since it cannot access grails-app/views via the classpath.

Given a newly created Grails application, the following test case, placed in test/integration:

class UrlMappingsTests extends grails.test.GrailsUrlMappingsTestCase {

void testViewMapping() { assertForwardUrlMapping('/', view:'index') }

}

cause the following stacktrace when running grails test-app:

java.io.FileNotFoundException: class path resource [grails-app/views/] cannot be resolved to URL because it does not exist
at grails.test.GrailsUrlMappingsTestCase.assertView(GrailsUrlMappingsTestCase.groovy:118)
at grails.test.GrailsUrlMappingsTestCase$assertView.callCurrent(Unknown Source)
at grails.test.GrailsUrlMappingsTestCase.assertForwardUrlMapping(GrailsUrlMappingsTestCase.groovy:149)
at grails.test.GrailsUrlMappingsTestCase$assertForwardUrlMapping$0.callCurrent(Unknown Source)
at grails.test.GrailsUrlMappingsTestCase.assertForwardUrlMapping(GrailsUrlMappingsTestCase.groovy:138)
at grails.test.GrailsUrlMappingsTestCase$assertForwardUrlMapping.callCurrent(Unknown Source)
at UrlMappingsTests.testViewMapping(UrlMappingsTests.groovy:4)

Activity

Hide
Bjorn Beskow added a comment -

Looks like it is because the PathMatchingResourcePatternResolver used by assertView uses DefaultResourceLoader (which loads resources from the Classpath), and '.' doesn't seem to be on the classpath.

A workaround is to configure the PathMatchingResourcePatternResolver to use a FileSystemResourceLoader instead.
The modified test case below does this in setUp(), and hence the test executes correctly.

import org.springframework.core.io.FileSystemResourceLoader
import org.springframework.core.io.support.PathMatchingResourcePatternResolver

class UrlMappingsTests extends grails.test.GrailsUrlMappingsTestCase {

void setUp() { super.setUp() patternResolver = new PathMatchingResourcePatternResolver(new FileSystemResourceLoader()) }
void testViewMapping() { assertForwardUrlMapping('/', view:'index') }

}

As far as I can see, the GrailsUrlMappingsTestCase.patternResolver is only used by assertView, and hence this change could be made to GrailsUrlMappingsTestCase?

/Björn

Show
Bjorn Beskow added a comment - Looks like it is because the PathMatchingResourcePatternResolver used by assertView uses DefaultResourceLoader (which loads resources from the Classpath), and '.' doesn't seem to be on the classpath. A workaround is to configure the PathMatchingResourcePatternResolver to use a FileSystemResourceLoader instead. The modified test case below does this in setUp(), and hence the test executes correctly. import org.springframework.core.io.FileSystemResourceLoader import org.springframework.core.io.support.PathMatchingResourcePatternResolver class UrlMappingsTests extends grails.test.GrailsUrlMappingsTestCase { void setUp() { super.setUp() patternResolver = new PathMatchingResourcePatternResolver(new FileSystemResourceLoader()) } void testViewMapping() { assertForwardUrlMapping('/', view:'index') } } As far as I can see, the GrailsUrlMappingsTestCase.patternResolver is only used by assertView, and hence this change could be made to GrailsUrlMappingsTestCase? /Björn
Hide
Graeme Rocher added a comment -

Thanks for the research and for posting a workaround

Show
Graeme Rocher added a comment - Thanks for the research and for posting a workaround
Hide
Bjorn Beskow added a comment -

The attached patch applies the above change to GrailsUrlMappingsTestCase.

Show
Bjorn Beskow added a comment - The attached patch applies the above change to GrailsUrlMappingsTestCase.
Hide
Graeme Rocher added a comment -

There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3

for 1.2 final only issues considered blocking will now be fixed

Show
Graeme Rocher added a comment - There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3 for 1.2 final only issues considered blocking will now be fixed
Hide
Luke Daley added a comment -

Moving to 1.4 as it is too big to go in the 1.3 line now.

Show
Luke Daley added a comment - Moving to 1.4 as it is too big to go in the 1.3 line now.
Hide
Colin Harrington added a comment - - edited

This seems like a simple patch. Why wasn't this just applied? Were there issues with this method?

Show
Colin Harrington added a comment - - edited This seems like a simple patch. Why wasn't this just applied? Were there issues with this method?

People

Vote (3)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: