<bean id="rod" class="Person" scope="singleton">
<constructor-arg>
Rod Johnson
</constructor-arg>
</bean>
<bean id="book" class="Book" scope="prototype">
<constructor-arg>
Expert One-on-One J2EE Design and Development
</constructor-arg>
<property name="author" ref="rod">
</property>
</bean>
and the same with Java configuration:
As Rod's blog mentions Spring configuration meta data is separate from the meta data parsing allowing varying configuration implementations. In addition to XML and Java other configuration options are popping up such as the Groovy Spring Builder and the Spring Annotation Project. Here is an example of a configuration using the Groovy Spring Builder: :@Configuration
public class MyConfig {
@Bean
public Person rod() {
return new Person("Rod Johnson");
}
@Bean(scope = Scope.PROTOTYPE)
public Book book() {
Book book = new Book("Expert One-on-One J2EE Design and Development");
book.setAuthor(rod()); // rod() method is actually a bean reference !
return book;
}
}
if(!dataSource) {
hibProps."hibernate.hbm2ddl.auto" = "create-drop"
}
else if(dataSource.dbCreate) {
hibProps."hibernate.hbm2ddl.auto" = dataSource.dbCreate
}
sessionFactory(ConfigurableLocalSessionFactoryBean) {
dataSource = dataSource
if(application.classLoader.getResource("hibernate.cfg.xml")) {
configLocation = "classpath:hibernate.cfg.xml"
}
hibernateProperties = { MapToPropertiesFactoryBean b ->
map = hibProps
}
grailsApplication = ref("grailsApplication", true)
classLoader = classLoader
}
transactionManager(HibernateTransactionManager) {
sessionFactory = sessionFactory
}
Community comments
Bad Groovy Builder example
by Colin Sampaleanu,
Scripting is probably best
by Thom Nichols,
Re: Scripting is probably best
by Rod Johnson,
Re: Scripting is probably best
by Rick Hightower,
Re: Scripting is probably best
by Rod Johnson,
Re: Scripting is probably best
by Corby Page,
Re: Scripting is probably best
by Graeme Rocher,
Re: Scripting is probably best
by ZedroS Schwartz,
Re: Scripting is probably best
by Jan Berkel,
Re: Scripting is probably best
by Graeme Rocher,
Re: Scripting is probably best
by Rusty Wright,
Re: Scripting is probably best
by Jan Berkel,
Bad Groovy Builder example
by Colin Sampaleanu,
Your message is awaiting moderation. Thank you for participating in the discussion.
That's not at all a great example of the Groovy Spring Bean builder. Any of the samples on the linked Groovy Builder page above gives a much better feel for the "builder" approach. You should replace the example.
The same "builder" style is possible in a language like Ruby/JRuby.
Colin
Scripting is probably best
by Thom Nichols,
Your message is awaiting moderation. Thank you for participating in the discussion.
I always thought XML was a bit awkward for configuration. Of course, the main advantage is that you can change the configuration without any compiling! So Java, annotations or not, would seem to be a let-down.
Groovy would seem to be ideal for the task and is practically a no-brainer to use. Although I agree with the above comment -- the Groovy example in the article is poor. See the examples on the Grails page.
I have feeling scripting is going to take a bigger role in these types of tasks (build scripts, rules engines, workflow templates) and relegate XML to more of a pure data representation role as it should be.
Re: Scripting is probably best
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
There are different types of configuration. Much configuration does benefit from being externalized, and XML (and properties files) as provided by Spring provide a great solution there. XML, among other things, has excellent tool support, and is nicely extensible with namespaces (which we've taken advantage of in Spring 2.0).
However, some configuration is still naturally external to the core business logic, but changes infrequently enough so that a compiled approach is just fine. And static checking as provided by a compiler adds value.
The Spring container is independent of any particular configuration source. So where I see this going is to assemble contributions from the different configuration requirements applications may have (Java, XML, properties, even database and LDAP) into a single rich component model. So that things that change at different rates are each in an appropriate format, and never need to modify your business object classes to change any configuration.
Re: Scripting is probably best
by Rick Hightower,
Your message is awaiting moderation. Thank you for participating in the discussion.
RE: Of course, the main advantage is that you can change the configuration without any compiling! So Java, annotations or not, would seem to be a let-down.
In practice I don't see the config files being modified much outside of the development effort. They become pretty static for a given application.
Also, with Eclipse incremental compile what is the disadvantage of putting things in Java. Perhaps you could limit the XML config to things that are likely to need configuration changes (which should be small for most apps that I have seen).
Re: Scripting is probably best
by Rusty Wright,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't understand why it's become so fashionable to bash using xml for configuring things. Unlike the so-called Domain Specific Languages, with xml you're more likely to get error messages that tell you what's wrong, rather than syntax errors that the so-called Domain Specific Language is hiding behind.
I'm not against using Ruby, Groovy, etc. for configuring stuff, but calling these configuration pseudo languages "Domain Specific" when they're really not, bugs me. To me, a true Domain Specific Language is one that has its own parser, and its error messages are specific to the domain it's designed for, and you can't use some other language (i.e., the host language like Ruby or Groovy) accidently or intentionally.
Re: Scripting is probably best
by Jan Berkel,
Your message is awaiting moderation. Thank you for participating in the discussion.
Martin Fowler refers to this type of DSL as
Internal DSLs. Basically you get a DSL plus all the features of the base language (no need to reimplement basic structures). This is really powerful, provided that all the developers know the base language, so it is a doubled-edged sword. XML is just the lowest common denominator everyone is familiar with.
Re: Scripting is probably best
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Rick
Yes: as I said, different types of configuration for different purposes.
Largely static configuration relating to object wiring => Java config
Not so static configuration relating to object wiring => XML
Stuff that changes all the time => XML
Simple values like database urls and passwords => properties files
Spring + Spring JavaConfig already covers all of this. In the future it would be great to supplement it with more dynamic sources of configuration like database-backed configuration.
Re: Scripting is probably best
by Corby Page,
Your message is awaiting moderation. Thank you for participating in the discussion.
More choices for everyone is awesome. But I find it pretty amusing that a lot of the people who are getting so excited about the Java config options are the same people who ranted about how XML config files get too large and out of control.
For simple configs that make up most of an app, the Java option is more verbose than the XML equivalent. I would love to use Java for some dynamic configuration, but using it as my default configuration option would be FUGLY. Maybe we've forgotten why Spring 1.0 became so much more popular than the traditional Builder pattern.
Re: Scripting is probably best
by Graeme Rocher,
Your message is awaiting moderation. Thank you for participating in the discussion.
Unfortunately none of these were good enough for us when doing Grails. The Java configuration option was not out at the time and even if it was it uses annotations, and doesn't cover all the bases.
With XML sure you get it update and change, but the problem is it is largely a static file. So if you're dealing with multiple environments and a convention-over-configuration approach like we are where you want the logic of the bean wiring to adapt to its environment and the conventions within the project, XML doesn't cut it.
And if you look at it every project has these same issues and traditionally you get round them by having an XML file for each environment for a single XML file with individual properties files read-in to adapt settings to the environment. However, the level of "adaption" is limited because XML is not a programming language and please don't try to make it one (see the horrors of Ant and XSLT).
The Groovy "mini-DSL" suites our use case perfect and in fact any use case that wants to use a convention over configuration approach and let the logic within your application adapt to its environment programmatically.
Re: Scripting is probably best
by ZedroS Schwartz,
Your message is awaiting moderation. Thank you for participating in the discussion.
Maybe there could be a way to reunite the best of the two worlds, by being able to initialise a config with some XML, update it with Groovy/DSL and then save it again in XML.
If the XML file could be modified by only one at a time, there would be few issue no ?
Re: Scripting is probably best
by Jan Berkel,
Your message is awaiting moderation. Thank you for participating in the discussion.
i like the idea, that's probably something which should be in the Spring core, say in form of a XMLBeanDefinitionWriter class which is able to serialize a spring config back to XML. as far as i know this doesn't exist at the moment, though.
Re: Scripting is probably best
by Graeme Rocher,
Your message is awaiting moderation. Thank you for participating in the discussion.
We do this with Grails. See grails.org/Runtime+Configuration+Plugins
Cheers
Graeme