19.1 Configuring Additional Beans

Using the Spring Bean DSL

You can easily register new (or override existing) beans by configuring them in grails-app/conf/spring/resources.groovy which uses the Grails Spring DSL. Beans are defined inside a beans property (a Closure):

  1. beans = {
  2. // beans here
  3. }

As a simple example you can configure a bean with the following syntax:

  1. import my.company.MyBeanImpl
  2. beans = {
  3. myBean(MyBeanImpl) {
  4. someProperty = 42
  5. otherProperty = "blue"
  6. }
  7. }

Once configured, the bean can be auto-wired into Grails artifacts and other classes that support dependency injection (for example BootStrap.groovy and integration tests) by declaring a public field whose name is your bean’s name (in this case myBean):

  1. class ExampleController {
  2. def myBean
  3. ...
  4. }

Using the DSL has the advantage that you can mix bean declarations and logic, for example based on the environment:

  1. import grails.util.Environment
  2. import my.company.mock.MockImpl
  3. import my.company.MyBeanImpl
  4. beans = {
  5. switch(Environment.current) {
  6. case Environment.PRODUCTION:
  7. myBean(MyBeanImpl) {
  8. someProperty = 42
  9. otherProperty = "blue"
  10. }
  11. break
  12. case Environment.DEVELOPMENT:
  13. myBean(MockImpl) {
  14. someProperty = 42
  15. otherProperty = "blue"
  16. }
  17. break
  18. }
  19. }

The GrailsApplication object can be accessed with the application variable and can be used to access the Grails configuration (amongst other things):

  1. import grails.util.Environment
  2. import my.company.mock.MockImpl
  3. import my.company.MyBeanImpl
  4. beans = {
  5. if (application.config.my.company.mockService) {
  6. myBean(MockImpl) {
  7. someProperty = 42
  8. otherProperty = "blue"
  9. }
  10. } else {
  11. myBean(MyBeanImpl) {
  12. someProperty = 42
  13. otherProperty = "blue"
  14. }
  15. }
  16. }
If you define a bean in resources.groovy with the same name as one previously registered by Grails or an installed plugin, your bean will replace the previous registration. This is a convenient way to customize behavior without resorting to editing plugin code or other approaches that would affect maintainability.

Using XML

Beans can also be configured using a grails-app/conf/spring/resources.xml. In earlier versions of Grails this file was automatically generated for you by the run-app script, but the DSL in resources.groovy is the preferred approach now so it isn’t automatically generated now. But it is still supported - you just need to create it yourself.

This file is typical Spring XML file and the Spring documentation has an excellent reference on how to configure Spring beans.

The myBean bean that we configured using the DSL would be configured with this syntax in the XML file:

  1. <bean id="myBean" class="my.company.MyBeanImpl">
  2. <property name="someProperty" value="42" />
  3. <property name="otherProperty" value="blue" />
  4. </bean>

Like the other bean it can be auto-wired into any class that supports dependency injection:

  1. class ExampleController {
  2. def myBean
  3. }

Referencing Existing Beans

Beans declared in resources.groovy or resources.xml can reference other beans by convention. For example if you had a BookService class its Spring bean name would be bookService, so your bean would reference it like this in the DSL:

  1. beans = {
  2. myBean(MyBeanImpl) {
  3. someProperty = 42
  4. otherProperty = "blue"
  5. bookService = ref("bookService")
  6. }
  7. }

or like this in XML:

  1. <bean id="myBean" class="my.company.MyBeanImpl">
  2. <property name="someProperty" value="42" />
  3. <property name="otherProperty" value="blue" />
  4. <property name="bookService" ref="bookService" />
  5. </bean>

The bean needs a public setter for the bean reference (and also the two simple properties), which in Groovy would be defined like this:

  1. package my.company
  2. class MyBeanImpl {
  3. Integer someProperty
  4. String otherProperty
  5. BookService bookService // or just "def bookService"
  6. }

or in Java like this:

  1. package my.company;
  2. class MyBeanImpl {
  3. private BookService bookService;
  4. private Integer someProperty;
  5. private String otherProperty;
  6. public void setBookService(BookService theBookService) {
  7. this.bookService = theBookService;
  8. }
  9. public void setSomeProperty(Integer someProperty) {
  10. this.someProperty = someProperty;
  11. }
  12. public void setOtherProperty(String otherProperty) {
  13. this.otherProperty = otherProperty;
  14. }
  15. }

Using ref (in XML or the DSL) is very powerful since it configures a runtime reference, so the referenced bean doesn’t have to exist yet. As long as it’s in place when the final application context configuration occurs, everything will be resolved correctly.

For a full reference of the available beans see the plugin reference in the reference guide.