This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Comment

I can't speak for the DataGraph team particularly, but we are currently at work on providing a consistent approach for java-based equivalents for Spring XML namespace elements in Spring 3.1 M2. Stay tuned to the blog for news on that, and in the meantime, I would suggest raising an issue against SDG to this effect. "Provide @Configuration alternatives for <datagraph:*/> elements" would do as a subject line.

With regard to Michael's suggestion on using a FactoryBean within a @Bean method, this is generally discouraged - it is awkward having to call the getObject() method, and means that the FactoryBean instance itself will not go through the normal container lifecycle. For example, if the FactoryBean implements InitializingBean, you'll need to call afterPropertiesSet() yourself - more awkwardness. It is acknowledged that this may be the only way to get it done in certain cases, but just furthers the need for SDG to provide @Configuration-friendly alternatives.

For one example of a 'more friendly' approach, take a look at what we've done with Spring's support for Hibernate in the forthcoming M2 release. As you may be familiar, Spring has always shipped FactoryBeans for Hibernate SessionFactory configuration - LocalSessionFactoryBean and AnnotationSessionFactoryBean, particularly.

In 3.1 M2, we've refactored these types to extend from more fundamental "SessionFactoryBuilder" types that are easy to use within @Bean methods. The FactoryBean types remain, but only for use within XML-based configuration.

Comment

We discussed that and are not so sure about pulling everyone who uses Spring Data projects to 3.1.M2, but an idea was to use profiles and have some support classes in there that are built against 3.1.M2.

Cheers

Michael

Comment

I've tried registering the FactoryBean within a @Bean method, but I'm finding that my @Autowired property within my @Configuration class is still null at the time when the FactoryBean is being registered within the @Bean method. My understanding was the @Autowired properties would be injected right after the construction of my @Configuration class, but the FactoryBean must be throwing off that sequence in the ApplicationContext lifecycle.

Comment

Thanks for the project. I've confirmed that this is in fact an issue, but need to investigate further as to a solution. I've created https://jira.springsource.org/browse/SPR-8514 to track the issue; please put a watch on it, as I won't update this forum thread further.

As a workaround in the meantime, consider changing the signature of your FactoryBean-returning @Bean method to be the actual target object type and calling factoryBean.getObject() to return it directly. You may need to call afterPropertiesSet() and other lifecycle methods.

Comment

Oliver Gierke and I also discussed adding support for @Configuration based repository factories but this means that we have to do some larger changes to the build as we want the spring data projects not to depend on Spring 3.1. but rather be usable with 3.0 too. So that will be about adding 3.1. support classes and building + testing everything against 3.1. and then against 3.0.5 and packaging and deploying with 3.0 dependencies.

It might take a while for that to get done though (we're also looking into converting the maven builds into gradle builds anyway).

Cheers

Michael

Comment

BTW for anyone who may be interested in this, I was able to register a BeanPostProcessor that is BeanFactoryAware in the application context; and this allowed me to auto detect all repositories (through ClassPathScanning) and register them in the ApplicationContext. This is all without any XML. This will work for the short term until DATACMNS-47 is resolved.