Google

Locations of visitors to this page

Bootstrapping

ti-core provides a very simple way to bootstrap dependent modules. The actual implementation relies on the information stored in the maven project metadata, in fact it reads the dependency configuration.

Knowing the dependent subsystems, the bootstrap logic reads the maven configuration information provided. Knowing the dependencies of the dependencies, ti-core is able to find all required modules recursively.

The bootstrapping logic searches for the spring runtime or test context configuration in the subsystems (jars) in the classpath.

ti-core relies on a naming pattern to find those configuration files, the standard naming and location pattern is:

/META-INF/<<artifactId>>-<<context>>-context.xml

The <<artifactId>> must match the artifacId defined in the project metadata (pom.xml). The <<context>> can be any string. The context in use is defined in the bootstrap process, see example below.

Every subsystem providing such configuration will get its runtime configuration loaded into the running application context. In future versions ti-core might create separate bean factories for each context.

The bootstrapping process is started by a special bootstrap component provided by the tiCore namespace, as shown in the sample bootstrap.xml spring context file below.

<?xml version="1.0" encoding="utf-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:tiCore="http://antidoto.sf.net/subsystem/ti-core"
	xsi:schemaLocation="
	http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd 
	http://antidoto.sf.net/subsystem/ti-core http://antidoto.sf.net/xsd/ti-core.xsd
	">

	<tiCore:bootstrap 
		groupId="net.sf.antidoto.doc" 
		artifactId="ti-core" 
		scope="test" 
		/>
</beans>

In the example above, all the /META-INF/<<artifactId>>-test-context.xml files will be loaded into the application context.

The bootstrap component defines a fall-back behaviour: if the configuration for some context for a specific artifactId (subsystem) is not found, it tries to load the runtime context configuration. This allows every subsystem to provide a default context configuration.

Nice to know

  • Maven2 deploys a copy of the pom in the packaged artifacts, thats how the "transitive dependecies" were implemented. ti-core relies on this mechanism to recursively find all dependent subsystems
  • Because of the dependency mediation in maven2 it is assured that only one version is in the classpath
  • The bootstrap logic relies on the Spring 2.x schema based configuration to get access to the bean registry to insert bean definitions