Bottom-up SOAP Services with Apache CXF and Custom XSD

SOAP is not very popular these days, primarily because of almost nonhuman readable WSDL and protocol that puts a lot of overhead into a simple message. It's tough to send a message using a browser or curl. Not mentioning the fact that we have to obtain WSDL somehow.

But on the other hand side, SOAP has some advantages over REST. It allows us to define a contract and specify the data it will process. Once you have such WSLD, you can throw it over the hedge, and you do not have to answer questions like how do I delete a created resource, what 403 means in this case, or is this call idempotent?
WSLD contains everything needed to define an RPC interface and document it. I would choose REST for most cases, but still, there are some good use cases for SOAP.

This one thing bothers me about SOAP: how do I get proper WSLD? Should I use a tool to generate it or write it? Honestly... I really do not want to dig into SOAP to just write WSLD, and I do not want to spend hours playing around with some tools generating WSLD, importing it into my project, and binding generated stuff to actual implementation only to find out about the end that it does not operate as expected.

The perfect solution would be to write Java code, annotate it, and generate WSDL out of it. Those annotations should provide enough flexibility to influence WSLD generation so that we archive something that can be delivered to the customers.

I've tried a few Java frameworks, and all provide a way to generate WSLD out of Java code, but they all need to include one fundamental feature: you cannot offer XSD for data types. So it's impossible to specify the content of an email field or provide a format for a date. We get only half of a possible functionality of a WSDL: method calls, exception handling, documentation, and security, but there is no way to specify the data format.
I would like to have WSLD that is as precise as possible so that the client can call the particular method and know precisely what is possible and is not allowed.

Let's start with the standard SOAP Service generated out of Java code. We will use Apache CXF and Spring Boot for it. The source code is here: https://github.com/maciejmiklas/apache-cxf-soap.

It's a simple application where users can submit registration as a SOAP Request on http://localhost:8080/soap/Registration:

	// http://localhost:8080/soap/Registration?wsdl
	@WebService(targetNamespace = NAMESPACE, serviceName = SERVICE_NAME)
	@SchemaValidation(type = BOTH)
	@SOAPBinding
	public class RegistrationService {
	private final Set<Registration> registered = new HashSet<>();
	@WebMethod
	public void register(Registration registration) throws AlreadyRegisteredException {
	if (registered.add(registration)) {
	throw new AlreadyRegisteredException();
	}
	}
	}
	@XmlRootElement
	class Registration {
	@XmlElement(required = true)
	private String email;
	@XmlElement(required = true)
	private String name;
	private String phone;
	private Integer age;
	// getters and setter omitted
	}
	@SpringBootApplication
	@Import(CxfConfiguration.class)
	public class ApacheCxfSoapApplication {
	@Bean
	public RegistrationService registrationService() {
	return new RegistrationService();
	}
	@Bean
	public JaxWsServiceFactoryBean jaxWsServiceFactoryBean() {
	JaxWsServiceFactoryBean serviceFactoryBean = new JaxWsServiceFactoryBean();
	serviceFactoryBean.setValidate(true);
	return serviceFactoryBean;
	}
	@Bean
	public JaxWsServerFactoryBean jaxWsServerFactoryBean() {
	return new JaxWsServerFactoryBean(jaxWsServiceFactoryBean());
	}
	@Bean
	public Endpoint registrationEndpoint(SpringBus springBus) {
	EndpointImpl endpoint = new EndpointImpl(springBus, registrationService(), jaxWsServerFactoryBean());
	endpoint.publish(SERVICE_ADDRESS);
	return endpoint;
	}
	public static void main(String[] args) {
	SpringApplication.run(ApacheCxfSoapApplication.class, args);
	}
	}

view raw apache-cxf-soap-o.java hosted with ❤ by GitHub

This code outpost following WSDL:

	<!-- http://localhost:8080/soap/Registration?wsdl -->
	<?xml version='1.0' encoding='UTF-8'?><wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://orginal.apachecxfsoap.ast.org/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" name="registration" targetNamespace="http://orginal.apachecxfsoap.ast.org/">
	<wsdl:types>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://orginal.apachecxfsoap.ast.org/" attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://orginal.apachecxfsoap.ast.org/">
	<xs:element name="register" type="tns:register"/>
	<xs:element name="registerResponse" type="tns:registerResponse"/>
	<xs:element name="registration" type="tns:registration"/>
	<xs:complexType name="register">
	<xs:sequence>
	<xs:element minOccurs="0" name="arg0" type="tns:registration"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="registration">
	<xs:sequence>
	<xs:element name="email" type="xs:string"/>
	<xs:element name="name" type="xs:string"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="registerResponse">
	<xs:sequence/>
	</xs:complexType>
	<xs:element name="AlreadyRegisteredException" type="tns:AlreadyRegisteredException"/>
	<xs:complexType name="AlreadyRegisteredException">
	<xs:sequence>
	<xs:element minOccurs="0" name="message" type="xs:string"/>
	</xs:sequence>
	</xs:complexType>
	</xs:schema>
	</wsdl:types>
	<wsdl:message name="registerResponse">
	<wsdl:part element="tns:registerResponse" name="parameters">
	</wsdl:part>
	</wsdl:message>
	<wsdl:message name="AlreadyRegisteredException">
	<wsdl:part element="tns:AlreadyRegisteredException" name="AlreadyRegisteredException">
	</wsdl:part>
	</wsdl:message>
	<wsdl:message name="register">
	<wsdl:part element="tns:register" name="parameters">
	</wsdl:part>
	</wsdl:message>
	<wsdl:portType name="RegistrationService">
	<wsdl:operation name="register">
	<wsdl:input message="tns:register" name="register">
	</wsdl:input>
	<wsdl:output message="tns:registerResponse" name="registerResponse">
	</wsdl:output>
	<wsdl:fault message="tns:AlreadyRegisteredException" name="AlreadyRegisteredException">
	</wsdl:fault>
	</wsdl:operation>
	</wsdl:portType>
	<wsdl:binding name="registrationSoapBinding" type="tns:RegistrationService">
	<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
	<wsdl:operation name="register">
	<soap:operation soapAction="" style="document"/>
	<wsdl:input name="register">
	<soap:body use="literal"/>
	</wsdl:input>
	<wsdl:output name="registerResponse">
	<soap:body use="literal"/>
	</wsdl:output>
	<wsdl:fault name="AlreadyRegisteredException">
	<soap:fault name="AlreadyRegisteredException" use="literal"/>
	</wsdl:fault>
	</wsdl:operation>
	</wsdl:binding>
	<wsdl:service name="registration">
	<wsdl:port binding="tns:registrationSoapBinding" name="RegistrationServicePort">
	<soap:address location="http://localhost:8080/soap/Registration"/>
	</wsdl:port>
	</wsdl:service>
	</wsdl:definitions>

view raw apache-cxf-soap-o.wsdl hosted with ❤ by GitHub

As you can see, this WSDL has little info about data types (lines 9-22). The email is mandatory, but there is no way to provide any further assertions.
The problem lies in JAXB. It ignores annotations to influence generated XML schema. There is a pull request (jaxb-facets) that would solve this issue, but it's already a few years old and looks like it will only be integrated for a while.

The limitation is not caused by SOAP frameworks but by the fact that they are based on JAXB.

This does not change the fact that I will not write WSLD myself. There has to be a better way!

We will implement a simple extension for Apache CXF to combine generated WSLD with custom XSD. We have to write XSD in this case, but CXF will generate WSLD for us and include the given schema.
XSD is mighty, so I prefer writing it by hand because it's possible to specify the data format precisely. Using annotations to generate XSD would be convenient, but it would still cover only some common areas.
The implementation below has its limitations. You might run into some issues. It might stop working after the next CXF update. But! I use it, and it does what I need, so it might be something for you as well ;)

Now we are going to modify the first example. The idea is to write XSD that defines simple types, references those types in transfer classes, and generates WSLD, combining them all.
In the beginning, we have to write a schema that defines types for transfer objects:

	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.0">
	<xs:simpleType name="email">
	<xs:restriction base="xs:string">
	<xs:maxLength value="256"/>
	<xs:minLength value="5"/>
	<xs:pattern
	value="([0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*@([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9})"></xs:pattern>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="phone">
	<xs:restriction base="xs:string">
	<xs:maxLength value="25" />
	<xs:minLength value="4" />
	<xs:pattern value="[0-9 ]+"></xs:pattern>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="age">
	<xs:restriction base="xs:integer">
	<xs:minInclusive value="0"></xs:minInclusive>
	<xs:maxInclusive value="120"></xs:maxInclusive>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="code">
	<xs:restriction base="xs:integer">
	<xs:minInclusive value="0"></xs:minInclusive>
	<xs:maxInclusive value="99999"></xs:maxInclusive>
	</xs:restriction>
	</xs:simpleType>
	</xs:schema>

view raw apache-cxf-soap-e.xsd hosted with ❤ by GitHub

The original source code will be modified only in a few places:

• We will replace the default Apache CXF data binding with a custom implementation. It reads Schama from the file and integrates it into generated WSLD,
• Some fields in transfer objects are annotated with @XmlSchemaType - this annotation provides a connection between Java types and types defined in XSD. For example, the ExRegistration#email is annotated with @XmlSchemaType(name = "email"), and XSD contains the email type. The email generated in WSDL references the type from a provided schema,
• the classes following the pattern *Registration* have been renamed to *ExRegistration*

	// http://localhost:8080/soap/ExRegistration?wsdl
	@WebService(targetNamespace = NAMESPACE, serviceName = SERVICE_NAME)
	@SchemaValidation(type = BOTH)
	@SOAPBinding
	public class ExRegistrationService {
	private final Set<ExRegistration> registered = new HashSet<>();
	@WebMethod
	public void register(ExRegistration registration) throws AlreadyRegisteredException {
	if (registered.add(registration)) {
	throw new AlreadyRegisteredException();
	}
	}
	}
	@XmlRootElement
	class ExRegistration {
	@XmlSchemaType(name = "email", namespace = NAMESPACE)
	@XmlElement(required = true)
	private String email;
	@XmlElement(required = true)
	private String name;
	@XmlSchemaType(name = "phone", namespace = NAMESPACE)
	private String phone;
	@XmlSchemaType(name = "age", namespace = NAMESPACE)
	private Integer age;
	// getters and setter omitted
	}
	@SpringBootApplication
	@Import(CxfConfiguration.class)
	public class ApacheCxfSoapExApplication {
	@Bean
	public ExRegistrationService registrationService() {
	return new ExRegistrationService();
	}
	@Bean
	public JaxWsServiceFactoryBean jaxWsServiceFactoryBean() {
	JaxWsServiceFactoryBean serviceFactoryBean = new JaxWsServiceFactoryBean();
	serviceFactoryBean.setValidate(true);
	return serviceFactoryBean;
	}
	@Bean
	public JaxWsServerFactoryBean jaxWsServerFactoryBean() {
	return new JaxWsServerFactoryBean(jaxWsServiceFactoryBean());
	}
	@Bean
	public Endpoint registrationEndpoint(SpringBus springBus) {
	EndpointImpl endpoint = new EndpointImpl(springBus, registrationService(), jaxWsServerFactoryBean());
	// THIS IS NEW
	SchemaJAXBDataBinding dataBinding = new SchemaJAXBDataBinding("types.xsd");
	endpoint.setDataBinding(dataBinding);
	// THIS IS NEW
	endpoint.publish(SERVICE_ADDRESS);
	return endpoint;
	}
	public static void main(String[] args) {
	SpringApplication.run(ApacheCxfSoapExApplication.class, args);
	}
	}
	class SchemaJAXBDataBinding extends JAXBDataBinding {
	private final String[] locations;
	private final static String FILTER_PATH = "//*[@type='tns:{}']";
	public SchemaJAXBDataBinding(String... locations) {
	super(true);
	this.locations = locations;
	}
	@Override
	public XmlSchema addSchemaDocument(ServiceInfo serviceInfo, SchemaCollection col, Document document, String systemId) {
	Arrays.stream(locations).map(this::load).forEach(xsd -> append(document, xsd));
	return super.addSchemaDocument(serviceInfo, col, document, systemId);
	}
	private void append(Document destination, Document extra) {
	Element root = destination.getDocumentElement();
	NodeList childNodes = extra.getDocumentElement().getChildNodes();
	IntStream.range(0, childNodes.getLength()).mapToObj(childNodes::item).
	filter(inNode -> contains(destination, inNode)).forEach(inNode -> {
	root.appendChild(destination.importNode(inNode, true));
	});
	}
	/**
	* filter out XSD types that are not referenced in WSDL.
	*/
	private boolean contains(Document doc, Node inNode) {
	if (inNode.getAttributes() == null || inNode.getAttributes().getNamedItem("name") == null) {
	return false;
	}
	Node node = inNode.getAttributes().getNamedItem("name");
	String exprStr = FILTER_PATH.replace("{}", node.getNodeValue());
	try {
	XPathExpression expr = XPathFactory.newInstance().newXPath().compile(exprStr);
	NodeList found = (NodeList) expr.evaluate(doc.getDocumentElement(), XPathConstants.NODESET);
	return found != null && found.getLength() > 0;
	} catch (XPathExpressionException e) {
	throw new InvalidXmlSchemaReferenceException("Error parsing document", e);
	}
	}
	private Document load(String location) {
	ResourceManager resourceManager = getBus().getExtension(ResourceManager.class);
	URL url = resourceManager.resolveResource(location, URL.class);
	if (url == null) {
	throw new InvalidXmlSchemaReferenceException("XSD not found: " + location);
	}
	try {
	Document document = StaxUtils.read(url.openStream());
	return document;
	} catch (IOException | XMLStreamException e) {
	throw new InvalidXmlSchemaReferenceException("Error reading XSD from: " + location, e);
	}
	}
	}

view raw apache-cxf-soap-e.java hosted with ❤ by GitHub

Here is our final WSDL:

	<?xml version='1.0' encoding='UTF-8'?><wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://extended.apachecxfsoap.ast.org/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" name="exRegistration" targetNamespace="http://extended.apachecxfsoap.ast.org/">
	<wsdl:types>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://extended.apachecxfsoap.ast.org/" attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://extended.apachecxfsoap.ast.org/">
	<xs:element name="exRegistration" type="tns:exRegistration"/>
	<xs:element name="register" type="tns:register"/>
	<xs:element name="registerResponse" type="tns:registerResponse"/>
	<xs:complexType name="register">
	<xs:sequence>
	<xs:element minOccurs="0" name="arg0" type="tns:exRegistration"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="exRegistration">
	<xs:sequence>
	<xs:element name="email" type="tns:email"/>
	<xs:element name="name" type="xs:string"/>
	<xs:element minOccurs="0" name="phone" type="tns:phone"/>
	<xs:element minOccurs="0" name="age" type="tns:age"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="registerResponse">
	<xs:sequence/>
	</xs:complexType>
	<xs:simpleType name="email">
	<xs:restriction base="xs:string">
	<xs:maxLength value="256"/>
	<xs:minLength value="5"/>
	<xs:pattern value="([0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*@([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9})"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="phone">
	<xs:restriction base="xs:string">
	<xs:maxLength value="25"/>
	<xs:minLength value="4"/>
	<xs:pattern value="[0-9 ]+"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="age">
	<xs:restriction base="xs:integer">
	<xs:minInclusive value="0"/>
	<xs:maxInclusive value="120"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:element name="AlreadyRegisteredException" type="tns:AlreadyRegisteredException"/>
	<xs:complexType name="AlreadyRegisteredException">
	<xs:sequence>
	<xs:element minOccurs="0" name="message" type="xs:string"/>
	</xs:sequence>
	</xs:complexType>
	</xs:schema>
	<!-- binding are identical to first WSDL-->

view raw pache-cxf-soap-e.wsdl hosted with ❤ by GitHub

Spring Beans Discovery through Java Config in Practice

Spring Java Config is a great tool that gives us a precise way to control an application's bootstrap and wiring. However, it only sometimes works as expected. We occasionally run into strange issues where a particular bean is not instantiated at the expected time, lazy loading does not work as expected, or the whole configuration is ignored for no apparent reason.

To get a better understanding of the inner workings of Spring bean discovery, I created some examples that can be found here: https://github.com/maciejmiklas/spring-context-test.git

Each example has a name: exa (example A) or exb (example B). Each example has several exercises, like exa has: exa01, exa02, ..., ex05.

Bean Loading Order - Single Config

https://github.com/maciejmiklas/spring-context-test/tree/master/src/main/java/org/test/context/exa

exa01

This is the first exercise. It defines a basic structure that will be modified as we go along.
The main method loads Spring context from the configuration file Conf.java. This configuration instructs Spring to create 3 beans. Each of these beans has two log statements, the first in the constructor and the second in @PostConstruct. The console output after the execution of this example is shown below the code.

	class ApplicationExA01 {
	public static void main(String[] args) {
	AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
	ctx.register(Conf.class);
	ctx.refresh();
	}
	}
	@Configuration
	class Conf {
	@Bean
	BeanA beanA() { return new BeanA(); }
	@Bean
	BeanB beanB() { return new BeanB(); }
	@Bean
	BeanC beanC() { return new BeanC(); }
	}
	class BeanA {
	public BeanA() {
	log("BeanA - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanA - postConstruct");
	}
	}
	class BeanB {
	public BeanB() {
	log("BeanB - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanB - postConstruct");
	}
	}
	class BeanC {
	public BeanC() {
	log("BeanC - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanC - postConstruct");
	}
	}

view raw exa01.java hosted with ❤ by GitHub

	>> BeanA - constructor
	>> BeanA - postConstruct
	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanC - constructor
	>> BeanC - postConstruct

view raw log.log hosted with ❤ by GitHub

Nothing spectacular happens here: beans are initialized from A to C right after the constructor Spring executes also @PostConstruct. There are no dependencies between the beans.

exa02

Let's modify the order of factory methods in Conf.java.

	@Configuration
	class Conf {
	@Bean
	BeanB beanB() {
	return new BeanB();
	}
	@Bean
	BeanA beanA() {
	return new BeanA();
	}
	@Bean
	BeanC beanC() {
	return new BeanC();
	}
	}

view raw exa02.java hosted with ❤ by GitHub

	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanA - constructor
	>> BeanA - postConstruct
	>> BeanC - constructor
	>> BeanC - postConstruct

view raw log.log hosted with ❤ by GitHub

The bean initialization order has changed. It means that method names do not matter, but the physical order within a class. It can change with JVM, so you should not rely on it!

exa03

Now we will extract the definition of BeanB into a dedicated configuration file:

	@Import({ConfBeanB.class})
	@Configuration
	class Conf {
	@Bean
	BeanA beanA() {
	return new BeanA();
	}
	@Bean
	BeanC beanC() {
	return new BeanC();
	}
	}
	@Configuration
	class ConfBeanB {
	@Bean
	BeanB beanB() {
	return new BeanB();
	}
	}

view raw exa03.java hosted with ❤ by GitHub

	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanA - constructor
	>> BeanA - postConstruct
	>> BeanC - constructor
	>> BeanC - postConstruct

view raw log hosted with ❤ by GitHub

Spring loads bean definitions from the imported configuration in the first place.

exa04

We will modify the previous exercise so that BeanB depends on BeanA.

	@Configuration
	class ConfBeanB {
	@Bean
	@DependsOn("beanA")
	BeanB beanB() {
	return new BeanB();
	}
	}

view raw exa04.java hosted with ❤ by GitHub

	>> BeanA - constructor
	>> BeanA - postConstruct
	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanC - constructor
	>> BeanC - postConstruct

view raw log hosted with ❤ by GitHub

Spring loads dependent beans in the first place. It does not matter where it's located. Spring will scan all possible configurations to find it.

exa05

The same as exa04, but BeanB does not have @DependsOn("beanA"). Instead, BeanB injects BeanA. We have a similar dependency situation to exa4: BanB depends on BeanA. However @PostConstructs are called in a different order: Spring creates an instance of BeanB, and during the construction phase (constructor), references to BeanA are not set. Once the instance of BeanB is created, BeanA will be created and injected into BeanB. BeanB cannot access BeanA in the constructor, first after a complete initialization is done - in the method @PostConstruct.
Spring had to modify the order of @PostConstruct calls to ensure that the bean references were not null during an initialization phase.

Summary

• within a single configuration class, the bean instantiation order depends only on the methods order within this class, not method names. However, this might depend on JVM,
• Spring loads, in the first place, imported bean definitions. The previous rule applies only to the situation where direct bean definitions do not depend on imported beans. If this is the case, Spring will load the dependent bean in the first place,
• the initialization code has to be placed in the @PostConstruct method and not in a constructor. Otherwise, references to some beans might be null.

Bean Loading Order - Mixed Config

https://github.com/maciejmiklas/spring-context-test/tree/master/src/main/java/org/test/context/exb

exb01

BeanA, BeanB, and BeanC are created through dedicated configuration classes: ConfBeanA, ConfBeanB, and ConfBeanC. BeanD is declared in Conf 

	class ApplicationExB01 {
	public static void main(String[] args) {
	AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
	ctx.register(Conf.class);
	ctx.refresh();
	log("Call BeanA");
	BeanA beanA = ctx.getBean(BeanA.class);
	beanA.method();
	}
	}
	@Import({ConfBeanA.class, ConfBeanB.class, ConfBeanC.class})
	@Configuration
	class Conf {
	@Bean
	BeanD beanD() {
	return new BeanD();
	}
	}
	class BeanA {
	public BeanA() {
	log("BeanA - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanA - postConstruct");
	}
	public void method() {
	log("BeanA - method");
	}
	}
	class BeanB {
	public BeanB() {
	log("BeanB - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanB - postConstruct");
	}
	public void method() {
	log("BeanB - method");
	}
	}
	class BeanC {
	public BeanC() {
	log("BeanC - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanC - postConstruct");
	}
	public void method() {
	log("BeanC - method");
	}
	}
	class BeanD {
	public BeanD() {
	log("BeanD - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanD - postConstruct");
	}
	public void method() {
	log("BeanD - method");
	}
	}
	@Configuration
	class ConfBeanA {
	@Bean
	BeanA beanA() {
	return new BeanA();
	}
	}
	@Configuration
	class ConfBeanB {
	@Bean
	BeanB beanB() {
	return new BeanB();
	}
	}
	@Configuration
	class ConfBeanC {
	@Bean
	BeanC beanC() {
	return new BeanC();
	}
	}

view raw exb01.java hosted with ❤ by GitHub

	>> BeanA - constructor
	>> BeanA - postConstruct
	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanC - constructor
	>> BeanC - postConstruct
	>> BeanD - constructor
	>> BeanD - postConstruct
	>> Call BeanA
	>> BeanA - method

view raw log hosted with ❤ by GitHub

Beans are created in order: A, B, C, D.

exb02

Similar to exb01, but the configuration class ConfBeanB has been renamed to ConfBeanXB.

	@Configuration
	class ConfBeanXB {
	@Bean
	BeanB beanB() {
	return new BeanB();
	}
	}

view raw exb02.java hosted with ❤ by GitHub

	>> BeanA - constructor
	>> BeanA - postConstruct
	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanC - constructor
	>> BeanC - postConstruct
	>> BeanD - constructor
	>> BeanD - postConstruct
	>> Call BeanA
	>> BeanA - method

view raw log hosted with ❤ by GitHub

The instantiation order remains unchanged.

exb03

The same as exb01, but the factory method in ConfBeanB has been renamed from beanB to xyz. The instantiation order remains unchanged.

exb04

The same as exb01, but BeanB has been renamed to BeanXB. This change did not influence instantiation order.

exb05

Similar to exb01, but we've changed the import order from A, B, C into B, A, C. The instantiation order has changed as well.

exb06

Same as exb01, but BeanC has been injected into BeanA. The instantiation order has been changed because BeanC had to be created before BeanA

Summary

• when the @Import statement contains multiple classes, Spring will load them from the left to the right side - it's iterating over an array, and names of configuration classes do not matter in this case,
• within single configuration class physical order of methods matters, not their names.

Duplicated Bean Name

exc01

We have 3 beans, A, B, and C, with dedicated config here. BeanA injects BeanB and BeanC.

	class ApplicationExC01 {
	public static void main(String[] args) {
	AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
	ctx.register(Conf.class);
	ctx.refresh();
	log("Call BeanA");
	BeanA beanA = ctx.getBean(BeanA.class);
	beanA.method();
	}
	}
	class BeanA {
	@Autowired
	private BeanC beanC;
	@Autowired
	private BeanB beanB;
	public BeanA() {
	log("BeanA - constructor, beanB:%s, beanC:%s", beanB, beanC);
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanA - postConstruct, beanB:%s, beanC:%s", beanB, beanC);
	}
	public void method() {
	log("BeanA - method");
	beanB.method();
	beanC.method();
	}
	}
	class BeanB {
	public BeanB() {
	log("BeanB - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanB - postConstruct");
	}
	public void method() {
	log("BeanB - method");
	}
	}
	class BeanC {
	public BeanC() {
	log("BeanC - constructor");
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanC - postConstruct");
	}
	public void method() {
	log("BeanC - method");
	}
	}
	@Import({ConfBeanA.class, ConfBeanB.class, ConfBeanC.class})
	@Configuration
	class Conf {
	}
	@Configuration
	class ConfBeanA {
	@Bean
	BeanA beanA() {
	return new BeanA();
	}
	}
	@Configuration
	class ConfBeanB {
	@Bean
	BeanB beanB() {
	return new BeanB();
	}
	}
	@Configuration
	class ConfBeanC {
	@Bean
	BeanC beanC() {
	return new BeanC();
	}
	}

view raw exc01.java hosted with ❤ by GitHub

	>> BeanA - constructor, beanB:null, beanC:null
	>> BeanC - constructor
	>> BeanC - postConstruct
	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanA - postConstruct, beanB:org.test.context.exc.exc01.BeanB@3e77a1ed, beanC:org.test.context.exc.exc01.BeanC@3ffcd140
	>> Call BeanA
	>> BeanA - method
	>> BeanB - method
	>> BeanC - method

view raw log hosted with ❤ by GitHub

exc02

The same as exc01, but we've renamed factory method ConfBeanB#beanB() into ConfBeanB#beanC(). Spring goes over our @Import declaration to determine all possible bean definitions: ConfBeanA, ConfBeanB, ConfBeanC. There are two factory methods with the same name: ConfBeanB#beanC() and ConfBeanC#beanC(), so ConfBeanC overwrites the bean created through ConfBeanB because it creates a bean with the same name.

exc03

Similar to exc02, but this time we've renamed method ConfBeanC#beanC() into ConfBeanC#beanB(), so that we have two methods beanB, and not as it was in exc02 two methods with the name: beanC. The output is still the same, BeanB is missing. We've just changed the name of the factory method, and we already know that names do not change loading order, and we still have two beans with the same name.

exc04

Similar to exc02, but we've changed the import order for config classes from A, B, C to A, C, B. Now ConfBeanB will get scanned on end, and it overwrites the previous bean with the same name, so BeanC is missing.

exc05 

It's a modified exc02. We've set AllowBeanDefinitionOverriding to false on Application Context. Bean overwriting is disabled now, so instead of bean not found, we are getting an exception that we are trying to register two beans under the same name.

exc06

The same as exc02, there are still two factory methods: beanC. Additionally, BeanB and BeanC are implementing the common interface. Now BeanA does not inject BeanB and BeanC directly but injects a collection of beans implementing our interface. In the case of direct injection, one of the beans was missing; now both are there!

Summary

In the case of two beans with the same name, the last one wins. You cannot directly inject such overwritten beans, but you can inject a collection of such beans sharing a common interface.

Lazy Loading

exd01

We have three beans: A, B, and C, and there are no dependencies between them. BeanC is being defined through a dedicated configuration class. Nothing special here. The initialization order is as expected.

exd02

The same as exd02, but we've annotated BeanB as lazy. Spring does not load BeanB at all. There are no dependencies to that bean.

exd03

Now we've injected BeanB into BeanA. @Lazy is set on injection point and bean definition. Additionally, we have defined a method on BeanA that calls a method on BeanB: ApplicationExD03 -> beanA.method() -> beanB.method()

	class BeanA {
	@Autowired
	@Lazy
	private BeanB beanB;
	public BeanA() {
	log("BeanA - constructor: %s", beanB);
	}
	@PostConstruct
	public void postConstruct() {
	log("BeanA - postConstruct");
	}
	public void method() {
	log("BeanA - method");
	beanB.method();
	}
	}
	@Configuration
	class ConfBeanB {
	@Bean
	@Lazy
	BeanB beanB() {
	return new BeanB();
	}
	}
	class ApplicationExD03 {
	public static void main(String[] args) {
	AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
	ctx.register(Conf.class);
	ctx.refresh();
	log("Call BeanA");
	BeanA beanA = ctx.getBean(BeanA.class);
	beanA.method();
	}
	}

view raw exd03.java hosted with ❤ by GitHub

	>> BeanA - constructor: null
	>> BeanA - postConstruct
	>> BeanC - constructor: null
	>> BeanC - postConstruct
	>> Call BeanA
	>> BeanA - method
	>> BeanB - constructor
	>> BeanB - postConstruct
	>> BeanB - method

view raw gistfile1.txt hosted with ❤ by GitHub

Spring postpones the creation of BeanB until the method is being called on it, @Lazy works as expected.

exd04

Same as exd03, but @Lazy has been removed on the injection point. BeanB is not lazy anymore, @Lazy on bean definition is not enough.

exd05

Same as exd03, but @Lazy has been removed from the bean configuration. BeanB is not lazy anymore, @Lazy on bean definition is not enough.

Summary

• lazy annotation has to be provided on configuration, and all injection points, otherwise Spring eagerly initializes such beans,
• lazy beans that are not referenced (injected) are not loaded at all,
• you should not rely on @Lazy unless you are 100% sure you can control all possible injection points. Otherwise, one missing Lazy-Annotation will disable laziness on the such bean.