bb.beans {
    xmlns aop:"http://www.springframework.org/schema/aop"

    album(Album)
    theAroundAspect(TheAspect)

    aop {
        config("proxy-target-class":true) {
            aspect( id:"myAspect", ref:"theAroundAspect" ) {
                around method:"invoke", pointcut: "execution(* webalbum.Album.*())"
            }
        }
    }
}

I merged these two ApplicationContext as follows:

def mainContext = grailsApplication.getMainContext()
def appCtx = bb.createApplicationContext()
addBeanDefinitions(appCtx, mainContext)

where addBeanDefinitions() is as follows:

private void addBeanDefinitions(ApplicationContext context, ApplicationContext mainContext) {
    DefaultListableBeanFactory scriptBeanFactory = context.autowireCapableBeanFactory
    for (name in  scriptBeanFactory.getBeanDefinitionNames()) {
        BeanDefinition definition = scriptBeanFactory.getBeanDefinition(name)
        mainContext.autowireCapableBeanFactory.registerBeanDefinition(name, definition)
    }
}

The problem is AOP in this case doesn't work on webalbum.Album domain object. However if I include Album object in BeanBuilder and use it from the ApplicationContext created with BeanBuilder, AOP works. Merge operation doesn't. Anything I am missing here?

Another problem I've observed with BeanBuilder DSL combined with XML ApplicationContext is double instantiation of the beans described by DSL inside XML. If you insert some debug output to JavaMessenger constructor you will see what I mean.

That's happening because of BeanBuilder's createApplicationContext method calls refresh() on created context and there is no way to call this method without context refreshing (BeanBuilder's API lack?).

I resolved this problem by overriding BeanBuilder's createRuntimeSpringConfiguration method to return my own implementation (extension) of DefaultRuntimeSpringConfiguration which in its turn skips refresh() in getApplicationContext:

public class MyBeanBuilder extends BeanBuilder {
    protected RuntimeSpringConfiguration createRuntimeSpringConfiguration(
                                     ApplicationContext parent, ClassLoader classLoader) {
        return new MyRuntimeSpringConfiguration(parent, classLoader);
    }
}

public class MyRuntimeSpringConfiguration extends DefaultRuntimeSpringConfiguration {

  public MyRuntimeSpringConfiguration(ApplicationContext parent, ClassLoader classLoader) {
        super(parent, classLoader);
  }

  public ApplicationContext getApplicationContext() {
      initialiseApplicationContext();
      registerBeansWithContext(context);
      //context.refresh();
      return context;
  }
}

Thanks!

BeanBuilder's DSL offers very comfortable way to define beans.
I tried sample and it works just fine!
But adding into spring configurations reveals some problems in the framework: it can not create customizer bean and fails with "Requested bean is currently in creation: Is there an unresolvable circular reference?" exception.
I tried the last Spring snapshot (2.5.5 20080606) – result is the same.
So, currently there is no way for use DSL together with AOP.

Thank you,
Alex

thanks for this interesting post. I'm quite interested in using Grails BeanBuilder, mainly in combination with XML-based bean definition files, e.g. for aop/tx-namespace based configuration of AOP or TX. What I would like most is something like JavaConfigs ConfigurationBeanPostProcessor for BeanBuilder. That would be even nicer then your suggestion, I think.

Regards and again thanks for your post!
Stefan

Nice post, just a few corrections/comments. We have created a separate jar called grails-spring-*.jar that contains only the BeanBuilder and its supporting classes. So you no longer need Grails core. Also it does now work without the servlet dependencies and there are two BeanBuilders: BeanBuilder and WebBeanBuilder. The latter extends BeanBuilder and takes a ServletContext etc.

All of this will be available officially in Grails 1.0 RC2, which will be out in the next week or so.

Also it should be noted that you can use BeanBuilder standalone without the need to embedd within XML if you want to take the Groovy DSL use further.

Again, great post.

Cheers,
Graeme