Customize how Orika compiles its generated source code

Provide your own implementation of CompilerStrategy to take over this behavior, or just extend the default ma.glasnost.orika.impl.generator.JavassistCompilerStrategy.

You can also use an alternative provided with Orika, ma.glasnost.orika.impl.generator.EclipseJdtCompilerStrategy which is helpful for step-debugging generated mapper code; more information about this alternative is described in the troubleshooting and debugging page.

compilerStrategy(CompilerStrategy compilerStrategy);

Customize how Orika resolved properties

Provide your own implementation of PropertyResolverStrategy to take over this behavior, or just extend the default ma.glasnost.orika.property.IntrospectorPropertyResolver.

Customize how Orika builds ClassMaps

Provide your own implementation of ClassMapBuilderFactory to take over this behavior, or just extend the default ma.glasnost.orika.metadata.ClassMapBuilder.Factory.

You can also use an alternative provided with Orika, ma.glasnost.orika.metadata.ScoringClassMapBuilder.Factory which uses a word-scoring algorithm to determine a best-fit matching of the fields for a pair of types; it even attempts to auto-resolve matches down to the nested properties and multi-occurrence elements.

Customize whether Orika will use auto-mapping

You can configure whether or not Orika will perform auto-mapping at runtime for types that were not registered; this behavior is enabled by default, but it can be disabled for cases where you want to be absolutely explicit about all classes that are mapped.

You can configure whether or not Orika will map null values from the source to destination. This behavior is enabled by default, but it can be disabled for cases where you want to leave the destination properties untouched if the source property contains a null value.