Develop Reference

Multiple Constructor injection ambiguity with spring boot

I am trying to learn to migrate one spring XML based application to spring boot application and wondering with one scenario where we have multiple constructors in a class and wish to inject all these using spring annotation.
I do understand and implemented the way using XML based configuration but confused with which annotation/way to inject multiple constructors.
I tried referring to few forums like : Ambiguity Regarding Spring Constructor Injection but no luck with spring boot.
Could anyone please help on this please?

As it was mentioned in comments you can use #Configuration
#Configuration
public class Config {
#Bean
public Employee employee() {
return new Employee(10,"100");
}
}

What is equivalent for `<jpa:repositories base-package="com.acme.repositories" />` in Java Config? [duplicate]

I'm trying to use spring data and spring config together in a small standalone application.
...
public static void main( String[] args )
{
ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
...
}
1. My question is how can I discover the spring data repositories without using
<jpa:repositories base-package="foo.repositories" />
by spring config ?
2. If not, can I use 'ClassPathXmlApplicationContext' and 'AnnotationConfigApplicationContext' together somehow ?

You can now use the annotation #EnableJpaRepositories("some.root.package") .
For example:
#Configuration
#EnableTransactionManagement(proxyTargetClass = true)
#EnableJpaRepositories("some.root.package")
#ComponentScan(basePackages = { "maybe.another.root.package" })
public class SystemConfiguration {
...
}
(Spring Data's announcement)

For completeness' sake and to address your second question: Yes, you can combine Java and XML configurations. This way you don't have to wait for the next Spring Data JPA release.
Just annotate your configuration class with ImportResource, like this:
#Configuration
#ImportResource("classpath:jpa-config.xml")
public class AppConfig {
...
}

This answer is now out of date.
Currently there's no equivalent for <jpa:repositories … /> yet. Feel free tor track the according JIRA ticket. The feature will be a major one for the upcoming GA releases of the JPA module (1.1) as well as MongoDB (1.1).

I think you should have a look at context:component-scan
<context:component-scan base-package="com.myProject"/>
It autodetects components annotated with #Repository/#Service/#Component . Check here for this .

Boot-strapping Spring Data JPA without XML

What is the Java #Configuration equivalent to:
<repositories base-package="com.acme.repositories" />
in Spring Data JPA? I am trying to get rid of XML configuration in favour to #Configuration classes, however reading through JpaRepositoryConfigDefinitionParser sources is fruitless.
The closest what I can get is:
#Bean
public RepositoryFactorySupport repositoryFactory() {
return new JpaRepositoryFactory(entityManagerFactory().createEntityManager())
}
#Bean
public BookDao bookDao() {
return repositoryFactory().getRepository(BookDao.class)
}
However the <repositories/> tag is much more functional: it automatically creates DAO for all interfaces extending CrudRepository found on CLASSPATH. Also it seems like my solution does not apply transactions to DAOs as opposed to default Spring Data JPA behaviour.

Spring Data JPA introduced #EnableJpaRepositories. See the reference documentation for details.

Looks like not possible yet: https://jira.springsource.org/browse/DATAJPA-69

Spring #Configuration and <context:component-scan />

I have a scenario configuring Spring Security on embedded Jetty which seems to be somewhat solved if I make use of JavaConfig to configure the Jetty server.
As a result, it's looking like JavaConfig rather than XML might be the better option for large chunks of the project. However, there are some niceties in the XML namespaces, like <context:component-scan /> which aren't readily available in a #Configuration setting.
I have discovered that ApplicationContextAware is honored for #Configuration classes, so the following is possible
#Configuration
public class FooConfig implements ApplicationContextAware {
#Override
public void setApplicationContext(ApplicationContext applicationContext) {
((AnnotationConfigApplicationContext) applicationContext).scan("org.example");
}
}
The alternative, which is documented, is to have the #Configuration class use an #ImportResource annotation and pull in an existing XML file:
#Configuration
#ImportResource("applicationContext-withComponentScan.xml")
public class BarConfig {}
I guess the question is "Is it bad form to abuse ApplicationContextAware in this way, or is it really not abuse"? Something just feels oddly dirty about the approach so I'd not be surprised if the Spring guys had covered this in some way or another that I've not spotted.
For the interested, the problem relates to scanning a Jersey setup with #Resource and #Provider classes that I'd rather not have to manually manage entries in a class/XML configuration.

Now that Spring 3.1 is ready and out, you can safely use #ComponentScan if you are on Spring 3.1. It's not only for Spring MVC as one of the outdated answers mentions. You can use it as follows:
#Configuration
#ComponentScan({"com.foo.bar", "org.foo.bar"})
public class AppConfig{ /** config code */ }
Here is the documentation http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/context/annotation/ComponentScan.html

Is it bad form to abuse ApplicationContextAware in this way, or is it really not abuse
Yes, this is bad form. If you're going to fetch things out of the context manually, you may as well not bother with dependency injection in the first place.
However, your second option (#ImportResource("applicationContext-withComponentScan.xml")) is a good one - this is current best practice when you want to use these XML macros in combination with annotation-style config.
A third option is to use the current milestone build of Spring 3.1, which adds a way of doing these things all in Java, using #Feature. This is not yet production-ready, though.

Check this link out as well. It is a bit more specific (for a web application) but it has a very nice code example for the scanning, specifically: http://static.springsource.org/spring/docs/current/javadoc-api/org/springframework/web/servlet/config/annotation/EnableWebMvc.html
from that link:
#ComponentScan(basePackages = { "org.example"} )

Setting Up Annotation Driven Transactions in Spring in #Configuration Class

So in the latest version of Spring we are able to use the #Configuration annotation to setup our configurations for Spring. Now in JavaConfig it is possible to use the #AnnotationDrivenTx (#AnnotationDrivenTx Reference Link) annotation to setup transactions in our Config class. But since JavaConfig has been decommissioned I was wondering if anyone knew how to setup something similar without JavaConfig and without needing to add anything to the application-context.xml. Here is what I basically have for my Config class
#Configuration
#ImportResource("config/application-context.xml")
public class Config {
public #Bean DataSource dataSource() {
//get and return datasource
}
public #Bean Service1 getService1() {
//return service1Impl
}
}
And I'd like to make Service1 transactional. If anyone has any ideas on how to do this or if this is just not possible please let me know.
Thanks!

You can now use #EnableTransactionManagement.
See this post for more details: http://blog.springsource.com/2011/06/10/spring-3-1-m2-configuration-enhancements/

It seems like it isn't possible according to this forum post:
there may be a more first-class
mechanism for enabling
annotation-driven TX in #Configuration
classes in Spring 3.1, but in the
meantime, the recommended approach is
to use #ImportResource to include a
snippet of XML that declares
<tx:annotation-driven/>
Wait: but you seem to have an XML context anyway. Why not add <tx:annotation-driven/> to it and use #Transactional?

Take a look at http://blog.springsource.com/2011/02/17/spring-3-1-m1-featurespec. Spring 3.1's FeatureSpecification classes such as TxAnnotationDriven are designed to solve exactly the problem described above.