GrailsApplicationAware vs. @Autowired

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GrailsApplicationAware vs. @Autowired

Benjamin Wolff
Hi,

I have a question regarding the preferred approach to get ahold of the grailsApplication instance in a non-artifact class.

We have an http filter class that requires the grailsApplication instance. The class is provided by a Grails plugin and is registered as a bean in the doWithSpring closure. The question is, whether it is ok to use the @Autowired annotation on the (typed) class member to get the instance injected, or should I implement the GrailsApplicationAware interface and provide the setter method? Both approaches work at runtime. Usually, I'd prefer the non-interface approach, but I don't know the side-effects when I use the annotation (testing mock up?). I've read that @Autowired resolves by bean type, whereas Grails resolves by bean name internally for the services, controllers, etc.

If possible, I would like to keep the declaration in the doWithSpring closure as clean as possible, so without any extra configuration:

def doWithSpring = {
    myBean(com.my.pkg.MyBean)
}

So what do you think?

Cheers,
Ben

Cheers,
Ben
Reply | Threaded
Open this post in threaded view
|

Re: GrailsApplicationAware vs. @Autowired

Ian Roberts
On 21/01/2013 08:58, Benjamin Wolff wrote:

> Hi,
>
> I have a question regarding the preferred approach to get ahold of the
> /grailsApplication/ instance in a non-artifact class.
>
> We have an http filter class that requires the /grailsApplication/ instance.
> The class is provided by a Grails plugin and is registered as a bean in the
> /doWithSpring/ closure. The question is, whether it is ok to use the
> /@Autowired/ annotation on the (typed) class member to get the instance
> injected, or should I implement the /GrailsApplicationAware/ interface and
> provide the setter method? Both approaches work at runtime. Usually, I'd
> prefer the non-interface approach, but I don't know the side-effects when I
> use the annotation (testing mock up?). I've read that /@Autowired/ resolves
> by bean type, whereas Grails resolves by bean name internally for the
> services, controllers, etc.

If you use javax.annotation.Resource instead of Autowired then it should
autowire by name rather than by type, i.e.

@Resource
def grailsApplication

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GrailsApplicationAware vs. @Autowired

Benjamin Wolff
Hi Ian,

I tried the suggested @Resource annotation and it seems to work fine at runtime.

So to sum this up, the @Resource annotation should be preferred, as it sticks to the Grails-internal mechanism for using artifact dependency mechanism. Furthermore, the @Resource annotation is a Java API so it even reduces the coupling to a concrete DI container. It can be used to avoid implementing the GrailsApplicationAware interface.

If my assumptions are not correct, please correct me ;).

Cheers,
Ben
Cheers,
Ben
Reply | Threaded
Open this post in threaded view
|

Re: GrailsApplicationAware vs. @Autowired

Benjamin Wolff
Just for the archives, there's an interesting read about the Spring DI annotations: http://blogs.sourceallies.com/2011/08/spring-injection-with-resource-and-autowired/
Cheers,
Ben