Development mode

For example auto-reloading and no caching of the message sources if development mode is active.

Development mode is activated if one of the following conditions applies:

Resource resolving

By default resources (eg. messages, templates) are resolved from the classpath. Development mode allows the configuration of a physical location for the resources of a module (eg on your local filesystem).

Default location
For simple Across based applications using @AcrossApplication it might be enough to simply activate development mode. If the working directory of the running application contains a src/main/resources directory, this directory would be used for all dynamic modules, unless a specific value is set. This would usually be the case for single maven module projects.

Specific module resource locations
The path can be configured by adding the right property to the application properties, or specifying them in the development mode properties. The development mode properties is a special properties file that by default will be looked for in ${user.home}/dev-configs/across-devel.properties.

A resource location for the development mode properties can be specified by setting the across.development.properties property value. Development mode properties are loaded using resource resolving, so classpath resources can be used as well (eg. classpath:/dev.properties).

The development mode properties file should contain properties where the key references the module name, and the value the physical resources directory.

Example development properties
# Absolute directory
acrossModule.MyModule.resources=c:/code/mymodule/src/main/resources
acrossModule.OtherModule.resources=c:/code/othermodule/src/main/resources

# Relative to the working directory
acrossModule.SomeModule.resources=some-module/src/main/resources
Using relative paths can be an effective way to embed development properties in a multi-module maven project. Paths should be relative to the working directory of the running application. Depending on how you run the application, the working directory can differ.
Properties added directly to the application properties will take precedence over those present in the development mode properties.

Developer tools

Development mode also activates support for Spring Boot DevTools. Devtools provide the developer with various productivity features, such as hot-reloading, where a recompile will apply your recent code changes instead of restarting the entire application.

Customizing the AcrossContext

The AcrossContext is the parent Spring ApplicationContext for all the modules that are present. By using the @AcrossApplication annotation, an AcrossContext will be configured.

After the initial configuration takes place and before any module has been bootstrapped, the configured AcrossContext will be delegated to all AcrossContextConfigurer beans it can find in the ApplicationContext. This allows the AcrossContext to be modified before the actual bootstrap happens.

Aside of configuring development mode, the across context can also be used to further customize beans and modules.

Example customizing an AcrossContext
@Configuration
@EnableAcrossContext
public class WebConfiguration implements AcrossContextConfigurer (1)
{
	@Bean
	public DataSource acrossDataSource() { (2)
		BasicDataSource dataSource = new BasicDataSource();
		dataSource.setDriverClassName( "org.hsqldb.jdbc.JDBCDriver" );
		dataSource.setUrl( "jdbc:hsqldb:mem:/hsql/testDataSource" );
		dataSource.setUsername( "sa" );
		dataSource.setPassword( "" );

		return dataSource;
	}

	@Override
	public void configure( AcrossContext context ) { (3)
		context.setDevelopmentMode( true );

		context.addModule( new SomeModule() );
	}
}
1 All AcrossContextConfigurers that are found in the ApplicationContext are called with the initial AcrossContext.
2 A datasource bean is created.
3 The AcrossContext is being injected and modified.
« Creating database schema Development mode Localization and translations »