Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<lang:groovy> tag in version 2.5 and higher doesn't work for refreshable Spring MVC endpoints [SPR-10689] #15317

spring-projects-issues opened this issue Jun 25, 2013 · 6 comments
status: bulk-closed


Copy link

spring-projects-issues commented Jun 25, 2013

Dhaval Powar opened SPR-10689 and commented


Dynamic language support is added to Spring by using the <lang:> namespace.
For eg. for a groovy script, the following xml should handle dynamic language support in Spring.

<lang:groovy id="refreshableMessenger" 
    <lang:property name="message" value="Hello World!"/> 

How this functions under the hood is:

  1. The <lang:groovy> instantiates the LangNamespaceHandler class which parses the xml and identifies the type of dynamic language ie. groovy, JRuby or BSH.

  2. LangNamespaceHandler then calls the registerScriptBeanDefinitionParser method which in turn, makes a call to registerBeanDefinitionParser to register the bean. The call to this method instantiates a ScriptBeanDefinitionParser object which does the following:

a. Resolve the script source
b. Set up infrastructure
c. Create script factory bean definition
d. and many more other specific functionalities....

In step (b.), to setup the architecture, the LangNamespaceUtils class sets up the scriptFactoryPostProcessor object. This object handles ScriptFactory definitions, replacing each factory with the actual scripted Java object generated by it.

The bug lies in the LangNamespaceUtils class due to an invalid variable initialization.

This class contains a variable name


The value of this variable is invalid because the full qualified name of the ScriptFactoryPostProcessor class is

This means that ScriptFactoryPostProcessor lies in the package and NOT org.springframework.scripting.config. Due to this the ScriptFactoryPostProcessor bean does not get instantiated and the dynamic language support does not work.

However, this issue did not exist in Spring 2.0 & earlier since the <lang:grovy> xml namespace and tag were handled in a different way. Please fix the bug.

Affects: 3.1.2

Reference URL:


Issue Links:

3 votes, 5 watchers

Copy link
Collaborator Author

spring-projects-issues commented Jun 25, 2013

Phil Webb commented

The SCRIPT_FACTORY_POST_PROCESSOR_BEAN_NAME provides the bean name of the ScriptFactoryPostProcessor, not the actual bean class. It is prefixed with org.springframework.scripting.config because that is the package where LangNamespaceUtils resides. If you looks at line 52 you should see that the bean class is

There are also some tests that should verify <lang:groovy> support.

Are you experiencing an actual problem with the tag? Would you be able to submit a issue project that can reproduce your problem?

Copy link
Collaborator Author

spring-projects-issues commented Jun 25, 2013

Dhaval Powar commented

Hi Phil,

Thanks for the quick reply. Yes, sorry, I seem to have missed that. You are right as far as the definition of the LangNamespaceUtils class. But this does not reflect well when it comes to processing the groovy script dynamically at runtime using the <lang:groovy> tag.

I am currently developing a Web application which makes RESTful calls using Spring annotations such as @RequestMapping etc.
So I am using groovy scripts which contains methods to which URLs are mapped using the Spring annotations. Now, I want to dynamically load the groovy scripts at runtime. The main reason of using groovy with spring is to implement HOT DEPLOYMENT. Having this, I can make changes to my groovy scripts while the server is running, and the changes will be caught at runtime and the script will be recompiled and reloaded without restarting the server.

So I first tried to use the lang:groovy notation in the applicationContext.xml but my scripts just do not get loaded at runtime and the URLs are not mapped to the respective handler methods.

However, then I created beans for the actual classes which makes load the groovy scripts, namely, and org.springframework.scripting.groovy.GroovyScriptFactory.

So I implemented the following beans..

<bean class="" />

<bean id ="User" class="org.springframework.scripting.groovy.GroovyScriptFactory">
     <constructor-arg value="classpath:controller/UserController.groovy" />

And with this definition, these beans do load the groovy scripts at runtime and the URLs are mapped to their respective handler methods. But using this definition, I am unable to implement the 'dynamic bean refresh' functionality. This can be done easily using the refresh-check-delay attribute in the lang:groovy tag.
I have provided detailed explanation of the problem at the following link. Please have a look and let me know as it has been almost a month that I am trying to get the dynamic functionality working.

Copy link
Collaborator Author

spring-projects-issues commented Oct 2, 2013

Seamus McMorrow commented

Is this something that is being worked on, or any update on it?

Copy link
Collaborator Author

spring-projects-issues commented Jan 13, 2014

Juergen Hoeller commented

Does this refer to the same scenario as #10935? In that case, setting proxy-target-class="true" on your lang:groovy tag should help...

Otherwise, target class annotations will not get exposed through the proxy and therefore not discovered by the MVC DispatcherServlet.


Copy link
Collaborator Author

spring-projects-issues commented Aug 1, 2018

venkata narayana commented

Any update on this as I am holding off upgrading my Spring version from 2.5.6 (this feature works on this version) to the latest and Java from 1.7 to 1.8. 

I recently tested on 5.0.8.RELEASE and no luck. I tried all the attribute combinations as per the doc:(

<lang:groovy id="nnService" script-source="classpath:com/vnn/apps/reload/ServiceImpl.groovy" scope="prototype" proxy-target-class="true" refresh-check-delay="1000"/>





@spring-projects-issues spring-projects-issues added type: bug status: waiting-for-triage labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: bug label Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed and removed status: waiting-for-triage labels Jan 11, 2019
Copy link
Collaborator Author

spring-projects-issues commented Jan 12, 2019

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
status: bulk-closed
None yet

No branches or pull requests

2 participants