Groovy refreshable bean & existing bean instances

[boekhold]

Hi all,

Kinda new to Spring, so maybe this is a stupid question. I'd like to use a groovy refreshable bean (<lang:groovy...>) with default scope, let's call it beanA. This bean will be wired into another bean, beanB

What happens when my groovy source file changes now? What will happen to the beanA instance that's wired into beanB?

I've had a look at the source for org.springframework.scripting.groovy.GroovyScriptF actory, and as far as I can tell, getScriptedObject() returns a fully instantiated GroovyObject. If I'm not mistaken that means that once a 'groovy bean' has been instantiated, it won't be 'updated' anymore if the groovy source file is modified. You will only get new instances as per the modified source for new calls to getBean(...).

Is my understanding correct? And if I'm correct, does that actually make sense then? Doesn't that restrict you enormously in the scenarios where you can use refreshable groovy beans?

For me, one very useful scenario would be where I define a bean "webServiceInvoker" with singleton scope, which is implemented as a groovy class script that uses the groovy-wslite library. I would really like to be able to modify that class script to update the way the web service call is made without having to restart my application all the time. Major time-saver during development of that webServiceInvoker... but (without having done any testing yet), I don't see how that would work with the current implementation.

Maarten

[boekhold]

Hi all,
What happens when my groovy source file changes now? What will happen to the beanA instance that's wired into beanB?

So, I decided to create a little test case (all written in groovy btw), and to my surprise this works as expected. I created an IoC container with a single beanA, which is written in groovy and has a single method "doit()" that just prints a message to stdout. Then a small test script creates a FileSystemXmlApplicationContext and does a getBean("beanA"). In a loop I then call beanA.doit().

To my surprise I could modify the script source for beanA, and it was picked up.

Based on this, I do believe that [i]somewhere[/] spring wraps a Proxy object around my groovy class. The proxy instance stays constant while the wrapped groovy class is 'swapped out' when the script source is modified. Another reason why I believe that is because at first I was getting a

java.lang.ClassCastException: sun.proxy.$Proxy5 cannot be cast to MainBean

exception if I just tried to call "beanA.doit()" from my groovy test script. I only got this working after I changed that to "beanA.invokeMethod("doit", null)".

Still, if anybody knows the final answer for this, I'd still be interested in an explanation on how this is *really* handled in spring.

Maarten