Added AnnotationConfigSupport.

[hekonsek]

Hi,

I've been browsing through the Spring Scala Jira and spotted issue [1] related to the autowiring support in Spring Scala.

While the author of the issue can just register regular AutowiredAnnotationBeanPostProcessor bean in order to use @Inject in his beans, this is not in sync with configuration style used in Spring XML.

In XML we would use <context:annotation-config/>. This is more higher level (aka DSL) approach than registering AutowiredAnnotationBeanPostProcessor explicitly in the context. The additional value gained from the <context:annotation-config/> is that it registers some other useful bean processors and that it uses AnnotationConfigUtils#registerAnnotationConfigProcessors under the hood. The usage of AnnotationConfigUtils cannot be overemphasized as it guarantees that only single instance of each annotation processor will be registered in the context.

I think that Scala Spring users should get their <annotation-config/> DSL to enable annotation-based configuration as well.

class ConfigWithoutTrait extends FunctionalConfiguration {

  annotationConfig = true

  bean("foo")(new Foo())

}

For Scala user preferring cake-like [2] configuration style we should provide AnnotationConfigSupport trait as well. The latter trait would enable annotation config the same way as annotationConfig = true does.

class ConfigWithoutTrait extends FunctionalConfiguration with AnnotationConfigSupport {

  bean("foo")(new Foo())

}

I believe that the proposed approach is the Scala-like way to provide this useful functionality to the FunctionalConfiguration users while keeping consistent style with the existing Spring XML goodies. What do you think about this idea?

[1] https://jira.springsource.org/browse/SCALA-5
[2] http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di

[poutsma]

I like the idea, but I am not sure about having the support in FunctionalConfiguration itself (in the form of the annotationConfig flag and the registration code). If we would use a similar solution for all the functionality offered by the XML context namespace (and other namespaces), FunctionalConfiguration would soon be quite cluttered with all kind of code that does not really belong there.

I am currently working on an alternative way of accomplishing this, by having a list of registration functions in FunctionalConfiguration that sub-traits can add to. I will put it up to my spring-scala fork as soon as it's done.

[poutsma]

Ok, I've put up the code at poutsma@3b27d49. Let me know what you think.

Note that I haven't merged the changes in #9 yet, so the order of the beans is significant. I will try to review and merge that request tomorrow.

[hekonsek]

I've been wondering do we really need a dedicated registration callbacks support to move this functionality into separated trait? I thought that delayedInit would be fine for our needs.

trait ContextSupport {

  self: FunctionalConfiguration =>

  private var annotationConfig = false

  def enableAnnotationConfig() {
     annotationConfig = true
  }    

  delayedInit{
    if(annotationConfig) {
      AnnotationConfigUtils.registerAnnotationConfigProcessors(beanRegistry)
    }
  }

}

However after the moment of consideration I think that introducing API for explicit registration callbacks will make the callbacks code more clear.

So yeah, +1 for your implementation :) .

However I would still consider adding AnnotationConfigSupport trait for cake-style configuration proponents.

trait AnnotationConfigSupport extends ContextSupport {

  enableAnnotationConfig()

}

Oh, and regarding the #9 - it doesn't fix the beans ordering, but BeanPostProcessor instances registration in general. Ordering is something that still needs to be addressed.

[poutsma]

Ok, I've merged my implementation.

I did not add the AnnotationConfigSupport trait (yet), because I don't quite understand what it adds. I don't see what it has to do with cake-style configuration either. Can you please explain?

[hekonsek]

Great Arjen, it's nice to see ContextSupport committed. I've notified [1] Daniel (the original requestor of the feature) how the final version of annotationConfig looks like.

Regarding the AnnotationConfigSupport. It follows the canonical cake pattern syntax where you mixin traits to enhanced object and keep the it unaware of being configured - val featuredObject = new Object extends FeatureA with FeatureB with FeatureC.

[1] https://jira.springsource.org/browse/SCALA-5#comment-88254