title: Autowiring custom-made Spring component in Grails
body: <p>I have a custom-made Spring which is bundled in a jar, which is then set as a dependency to my Grails app. I load the app-context for the bean with importBeans statement in resoueces.groovy like</p>
  
  <pre><code>beans = {
    importBeans('classpath:app-context-my-component.xml')
  }
  </code></pre>
  
  <p>The <code>app-context-my-component.xml</code> has some bean definitions and the following lines</p>
  
  <pre><code>&lt;context:annotation-config /&gt;
  &lt;context:property-placeholder location="classpath:my-component.properties" /&gt;
  </code></pre>
  
  <p>The component I'm trying to use with Grails is annotated with <code>@Component("myComponent")</code>.</p>
  
  <p>Grails is loading the external application context. I know it because I first didn't have the .properties file on classpath and there we're no fallback mechanism for missing property in my @Value declarations.</p>
  
  <p>In the Grails controller, the component is used as</p>
  
  <pre><code>class MyController {
  
    def myComponent
  
    def someaction() {
      myComponent.doSomething()
    }
  }
  </code></pre>
  
  <p><strong>The result is a NullPointerException i.e. the autowiring of the component didn't work after all</strong>. I tried to use @Autowired in the controller, but that gave such a strange problems that I thought it cannot be the road I want to take.</p>
  
  <p><strong>Grails version in use is 2.3.6</strong>
  The Spring component is also set to use <strong>Spring version 3.2.7</strong> to avoid incompatibilities.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Now with again time in my hands for this issue, I set up Spring logging in order to figure out what's happenig. Well, there's plenty of log that Spring context loading produces, but here's what I managed to grep from the whole lot</p>
  
  <pre><code>INFO xml.XmlBeanDefinitionReader Loading XML bean definitions from class path resource [app-context-my-component.xml]
  INFO support.PropertySourcesPlaceholderConfigurer Loading properties file from class path resource [my-component.properties]
  DEBUG framework.CglibAopProxy Unable to apply any optimisations to advised method: public myapp.external.MyComponent myapp.MyService.getMyComponentClient()
  DEBUG framework.CglibAopProxy Unable to apply any optimisations to advised method: public myapp.external.MyComponent myapp.MyService.getMyComponentClient()
  DEBUG framework.CglibAopProxy Unable to apply any optimisations to advised method: public myapp.external.MyComponent myapp.MyService.getMyComponentClient()
  DEBUG framework.CglibAopProxy Unable to apply any optimisations to advised method: public void myapp.MyService.setMyComponentClient(myapp.external.MyComponent)
  DEBUG framework.CglibAopProxy Unable to apply any optimisations to advised method: public void myapp.MyService.setMyComponentClient(myapp.external.MyComponent)
  DEBUG framework.CglibAopProxy Unable to apply any optimisations to advised method: public void myapp.MyService.setMyComponentClient(myapp.external.MyComponent)
  </code></pre>
  
  <p>I changed the namespaces of the log, but <em>myapp.external</em> namespace refers to the external jar package, and <em>myapp</em> namespace refers to Grails application namespace. I have changed the usage, so that the external component is used from a Service instead of directly from Controller, but that detail had no change in the behaviour.</p>
  
  <p>Per my understanding, the Spring context loading went well.</p>
  
  <p><strong>UPDATE 2</strong></p>
  
  <p>Based on <strong>@th3morg</strong>'s answer I got an idea to try with XML-based config only, skipping all @Component and such annotations from the bean. And it worked! Now Grails manages to import the beans an no longer causes NPE on use.</p>
  
  <p><strong>Although this solves my problem, at least partially. I'm still interested in solution where Spring annotations could be used.</strong></p>