GenericGroovyApplicationContext propagates BeanDefinitionParsingException only when context file is named 'beans.groovy' [SPR-12435]

[spring-projects-issues]

Grzegorz Ćwiak opened SPR-12435 and commented

GenericGroovyApplicationContext propagates BeanDefinitionParsingException only when context file is named 'beans.groovy'

Given:
incorrect groovy bean config:

beans = {

foo String, 'hello'

}

Here '=' sign in this place is a mistake.

When instantiating the context:
GenericGroovyApplicationContext context = new GenericGroovyApplicationContext("classpath:beans.groovy");

It behaves differently depending on file name of the corrupted groovy config:

• when it is named in any other way than 'beans.groovy', e.g. 'myServiceContext.groovy', than no exception is thrown, the context starts up but without any beans created, context.getBeanDefinitionCount() returns 0.

• when it is named 'beans.groovy' the following error is reported:
  org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Error evaluating Groovy script: startup failed:
  beans.groovy: 1: you tried to assign a value to the class 'beans'. Do you have a script with this name?
  @ line 1, column 1.
  beans = {
  ^

1 error

Offending resource: class path resource [beans.groovy]; nested exception is org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
beans.groovy: 1: you tried to assign a value to the class 'beans'. Do you have a script with this name?
@ line 1, column 1.
beans = {
^

1 error

at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:309)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:927)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:575)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:524)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:279)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:258)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:613)
at groovy.lang.GroovyShell.parse(GroovyShell.java:625)
at groovy.lang.GroovyShell.parse(GroovyShell.java:605)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:586)
at org.springframework.beans.factory.groovy.GroovyBeanDefinitionReader.loadBeanDefinitions(GroovyBeanDefinitionReader.java:229)
at org.springframework.beans.factory.groovy.GroovyBeanDefinitionReader.loadBeanDefinitions(GroovyBeanDefinitionReader.java:196)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:180)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:216)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:187)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:251)
at org.springframework.context.support.GenericGroovyApplicationContext.load(GenericGroovyApplicationContext.java:195)

---

Affects: 4.0.2

[spring-projects-issues]

Juergen Hoeller commented

This is caused by Groovy's own parser reacting to the specified filename, going into a class parsing/validation mode when the top-level element matches the filename.

Since we're driving that parse step through Spring's GroovyBeanDefinitionReader, we're adding the concrete user filename to exception messages anyway - and can simply always specify "beans" as the filename for Groovy parsing purposes, leading to consistent failure on structural mistakes.

Juergen