I am trying to understand it as well. It looks like calling refresh() is mandatory on any context if new bean definitions were registered. As a result, the whole configuration is reloaded and singletons are recreated.

For plugin-like purposes I want to be able to append a new bean on-the-fly using beans from a static XML configuration as dependencies. I have not googled anything like that. Most links are about OSGI

I do have one question though. Is there a way to do a hybrid approach where you define some of the configuration in xml and some of it programmatically as in your example?

I know it sounds like a strange request, but I do have some code where it would be very useful.

I’ve included the code for the curious.

//XLogger.java
package com.xiotl.xdb.test;

public interface XLogger {
void log(String msg);
}

//Test.java
package com.xiotl.xdb.test;

import org.springframework.beans.factory.support.BeanDefinitionBuilder;
import org.springframework.context.support.GenericApplicationContext;
import org.springframework.scripting.support.ScriptFactoryPostProcessor;

public class Test {

public static void main(String[] args) {

//Declare the ApplicationContext
GenericApplicationContext ctx = new GenericApplicationContext();

//Define and register the post processor
BeanDefinitionBuilder bdb1 = BeanDefinitionBuilder
.rootBeanDefinition(”org.springframework.scripting.support.ScriptFactoryPostProcessor”)
.setLazyInit(false);
ctx.registerBeanDefinition(”scriptPostProcessor”, bdb1.getBeanDefinition());

//define the script location… in my case it is inline,
// but any standard classpath:/package/script.groovy style location can be used
String location = ScriptFactoryPostProcessor.INLINE_SCRIPT_PREFIX + “package com.xiotl.xdb.test\n” +
“\n” +
“import org.apache.log4j.Logger\n” +
“\n” +
“class Scratch implements XLogger {\n” +
” private static Logger logger = Logger.getLogger(\”XLogger\”);\n” +
“\n” +
” public void log(String message) {\n” +
” logger.info(message);\n” +
” }\n” +
“}”;
//define and register the groovy bean
BeanDefinitionBuilder bdb2 = BeanDefinitionBuilder
.rootBeanDefinition(”org.springframework.scripting.groovy.GroovyScriptFactory”)
.addConstructorArg(location);
ctx.registerBeanDefinition(”groovyLogger”, bdb2.getBeanDefinition());
//refresh the context
ctx.refresh();
//get the bean
XLogger xlog = (XLogger)ctx.getBean(”groovyLogger”);
//test the bean
xlog.log(”A Message from Groovy”);
}

}

i am using the programmatic approach for bean creation to create a test harness which has its own XML language whose xsd is registered with Spring. Every thing is working perfectly but i was wondering what will happen when thousands of test cases will be run together. Each test case will create its own object and there will be a large number of objects in memory. Will this cause a problem ? Any Thoughts ? work arounds ?

If you’re building a hosted app or single deployment type apps (i.e. desktop) there are probably very few areas I would use this for unless I was loading a lot of smaller ApplicationContexts or child contexts where they were dynamic based on say, user or account settings.

However, coding is like the English language. There’s always an exception to every rule.