One of the quickest ways to get more information about what Orika is doing as it attempts to map your classes is to set the logging level to DEBUG on the ma.glasnost.orika package. This will result in information such as the following being displayed in your logs/console/etc.:
08:56:01.910 [main] DEBUG m.g.orika.metadata.ClassMapBuilder - ClassMap created: ClassMapBuilder.map(BookImpl, BookDTOWithAltCaseEnum) .field([format(PublicationFormat)], [format(PublicationFormatDTOAltCase)]) .field([title(String)], [title(String)])
08:56:01.928 [main] DEBUG m.g.o.impl.generator.MapperGenerator - Generating new mapper for (BookImpl, BookDTOWithAltCaseEnum)
OrikaBookDTOWithAltCaseEnumBookImplMapper892899908.mapAToB(BookImpl, BookDTOWithAltCaseEnum) {
Field(format(PublicationFormat), format(PublicationFormatDTOAltCase)) : using converter LegacyConverter(ma.glasnost.orika.test.enums.EnumsTestCase$1@150ac9a8)
Field(title(String), title(String)) : treating as immutable (using copy-by-reference)
}
OrikaBookDTOWithAltCaseEnumBookImplMapper892899908.mapBToA(BookDTOWithAltCaseEnum, BookImpl) {
Field(format(PublicationFormatDTOAltCase), format(PublicationFormat)) : mapping from String or enum to enum
Field(title(String), title(String)) : treating as immutable (using copy-by-reference)
}
Types used: [PublicationFormatDTOAltCase]
Converters used: LegacyConverter(ma.glasnost.orika.test.enums.EnumsTestCase$1@150ac9a8)]
08:56:01.929 [main] DEBUG m.g.orika.impl.MapperFacadeImpl - MappingStrategy resolved and cached:
Inputs:[ sourceClass: ma.glasnost.orika.test.enums.EnumsTestCaseClasses.BookImpl, sourceType: BookImpl, destinationType: BookDTOWithAltCaseEnum]
Resolved:[ strategy: InstantiateByDefaultAndUseCustomMapperStrategy, sourceType: BookImpl, destinationType: BookDTOWithAltCaseEnum, mapper: ma.glasnost.orika.generated.OrikaBookDTOWithAltCaseEnumBookImplMapper892899908@560c7816, mapInverse?: false]
Orika uses slf4j, so it should be able to support most logging implementations using the proper bridge.
If you’re not getting the expected results out of Orika (or you want to contribute a fix or feature) and there’s not enough info available in the logs to resolve the problem, you may wish to download the source and step through the mapping process to see the details.
To enable step-through debugging into the generated objects (which Orika is building at run-time), you’ll need to include the orika-eclipse-tools module in your project, like so:
<dependency> <groupId>ma.glasnost.orika</groupId> <artifactId>orika-eclipse-tools</artifactId> <version>1.4.0</version><!-- please verify the latest version --> </dependency>
In addition, you’ll also need to tell Orika you want to use Eclipse Jdt as the compiler strategy; there are 2 ways to do this, listed in order of precedence:
DefaultMapperFactory.Builder.compilerStrategy(...) method, like so:
MapperFactory factory =
new DefaultMapperFactory.Builder()
.compilerStrategy(new EclipseJdtCompilerStrategy())
.build();
// add mappers, hints, converters, etc...
// Maybe more convenient, but sets at a global level... System.setProperty(OrikaSystemProperties.COMPILER_STRATEGY,EclipseJdtCompilerStrategy.class.getName());
If you’re using Eclipse as your IDE, you may initially receive the “Source not found” window with a button labeled “Edit Source Lookup Path…” while trying to (debug) step into the source of a generated object. When you click this button, you’ll need to add the location of the compiler output folder for your project as a File System Folder (not a Workspace Folder). This is due to the fact that source files will not actually exist until just before you reach the break-point and Eclipse will have a “stale” view of the workspace folder by that time.
If you’re using an IDE other than Eclipse, the procedure should be similar. Note that although Orika is leveraging the Eclipse Jdt core functions to format and compile the code, it resolves these from it’s own dependencies, so if using Maven, there should be few differences.
If your project follows the Maven folder structure, this folder would be the target/test-classes folder by default. Check your project configuration build path to see the target location if you’re unsure.
If not using Maven, you’ll need to make sure the following Eclipse Jdt artifacts are added to the build path:
| jdt artifact | version |
|---|---|
| core | 3.5.2 |
| text | 3.3.0 |
| commands | 3.3.0 |
| runtime | 3.3.100 |
| osgi | 3.3.0 |
| common | 3.3.0 |
| jobs | 3.3.0 |
| registry | 3.3.0 |
| preferences | 3.2.100 |
| contenttype | 3.2.100 |
Will other versions work (such as the latest from your own Eclipse IDE)? Probably…but we haven’t confirmed this yet
If you receive an exception like org.eclipse.core.runtime.ListenerList? singing information doesn’t match…, try moving the eclipse binaries to the front of the classpath; if you’re using maven, just move the orika-eclipse-tools dependency before orika-core and you’re done.
When using Javassist (the default) as the compiler strategy, Orika will not generate source or class files by default. When using Eclipse Jdt, Orika will generate source but not class files by default.
This behavior can be customized by setting some special system properties, like so:
// Write out source files to (classpath:)/ma/glasnost/orika/generated/ System.setProperty(OrikaSystemProperties.WRITE_SOURCE_FILES,"true"); // Write out class files to (classpath:)/ma/glasnost/orika/generated/ System.setProperty(OrikaSystemProperties.WRITE_CLASS_FILES,"true");
Note that when using Javassist, the debug info is not being generated so you can look at the code, but you normally can’t step into it during a debug session.
You may also need to apply the auto-formatting feature of your favorite IDE to the Javassist strategy source as we’re not really shooting for style points on these (normally in-memory only) classes.
The Eclipse strategy generated files includes auto-formatting of the source and includes debug info so that you can step into the code during a debug session (as mentioned in the section above).