GrailsApplication MainContext vs ParentContext - what to use?

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

GrailsApplication MainContext vs ParentContext - what to use?

sergiomichels
Normally when I need a bean I use:


grailsApplication.getMainContext().getBean("myService")

Looking at unit tests, it's possible to define beans that will be used, something like:


defineBeans {
  myService(MyService)
}

The GrailsUnitTestMixin declare this beans as grailsApplication.parentContext, and the example showed above breaks. Is this intended? Why the unit test use the parentContext instead of mainContext? Getting beans through the mainContext is wrong?


--
Sérgio Michels

Reply | Threaded
Open this post in threaded view
|

Re: GrailsApplication MainContext vs ParentContext - what to use?

sergiomichels
I found some explanation for the difference between parent and main context in the docs:

  • Grails constructs a parent ApplicationContext from the web-app/WEB-INF/applicationContext.xml file. This ApplicationContext configures the GrailsApplication instance and theGrailsPluginManager.
  • Using this ApplicationContext as a parent Grails' analyses the conventions with the GrailsApplication instance and constructs a child ApplicationContext that is used as the rootApplicationContext of the web application
If I understand correctly, the beans defined in a unit test should be in the mainContext since the parentContext is to hold the grailsApplication and the plugin manager.






--
Sérgio Michels



On Thu, Nov 29, 2012 at 10:56 AM, Sergio Michels <[hidden email]> wrote:
Normally when I need a bean I use:


grailsApplication.getMainContext().getBean("myService")

Looking at unit tests, it's possible to define beans that will be used, something like:


defineBeans {
  myService(MyService)
}

The GrailsUnitTestMixin declare this beans as grailsApplication.parentContext, and the example showed above breaks. Is this intended? Why the unit test use the parentContext instead of mainContext? Getting beans through the mainContext is wrong?


--
Sérgio Michels


Reply | Threaded
Open this post in threaded view
|

Re: GrailsApplication MainContext vs ParentContext - what to use?

zyro
anyone knows why the beans defined via defineBeans {} are put into the
parentContext, not the mainContext?

zyro

-------- Original Message  --------
Subject: Re: [grails-user] GrailsApplication MainContext vs
ParentContext - what to use?
From: Sergio Michels <[hidden email]>
To: [hidden email]
Date: Thu, 29 Nov 2012 15:27:27 -0200

> I found some explanation for the difference between parent and main
> context in the docs:
>
>   * Grails constructs a parent ApplicationContext from the
>     web-app/WEB-INF/applicationContext.xml file. This ApplicationContext
>     configures the GrailsApplication instance and theGrailsPluginManager.
>   * Using this ApplicationContext as a parent Grails' analyses the
>     conventions with the GrailsApplication instance and constructs a
>     child ApplicationContext that is used as the rootApplicationContext
>     of the web application
>
> If I understand correctly, the beans defined in a unit test should be in
> the *mainContext *since the parentContext is to hold the
> grailsApplication and the plugin manager.
>
>
>
>
>
>
> --
> Sérgio Michels
>
>
>
> On Thu, Nov 29, 2012 at 10:56 AM, Sergio Michels
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Normally when I need a bean I use:
>
>
>     |grailsApplication.getMainContext().getBean("myService")|
>
>
>     Looking at unit tests, it's possible to define beans that will be
>     used, something like:
>
>
>     |defineBeans {
>       myService(MyService)
>     }|
>
>
>     The GrailsUnitTestMixin declare this beans as
>     grailsApplication.parentContext, and the example showed above
>     breaks. Is this intended? Why the unit test use the parentContext
>     instead of mainContext? Getting beans through the mainContext is wrong?
>
>
>     --
>     Sérgio Michels
>
>

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

    http://xircles.codehaus.org/manage_email