In Stitch, there is additional logging available that you can use for troubleshooting when something goes wrong.
To collect and view the additional logging information, enable the
trace log level for the Stitch package, in the
conf/logback.xml file as shown below:
<logger name="com.xebialabs.deployit.plugin.stitch" level="trace"/>
Here are some common problems that might appear:
I have an error when my rule is applied Troubleshoot: Add trace level logging to the log input with its parameters before the processor is being applied, and also log the result of every processor application. It might give you a clue of what might go wrong between every processor.
<logger name="com.xebialabs.deployit.plugin.stitch.service.engine.pipeline" level="trace"/>
- I have an error when syncing my repository:
Troubleshoot: When a sync fails the status of the last sync will be shown in the Workbench for a specific source.
To see sync errors in the log, you can set the log level to debug for the
com.xebialabs.deployit.plugin.stitch.service.engine.indexpackage. It will log the process of source synchronization, the amount of Stitch YAML definitions in the source, and the exception which is thrown in case of any error occurs during source synchronization.
<logger name="com.xebialabs.deployit.plugin.stitch.service.engine.index" level="debug"/>
- My rule does not fire, and I don’t know why:
For every input, the Stitch Engine will print the total amount of processors that will be applied to the input.
If the rule is not fired, you may add debug logging to the
com.xebialabs.deployit.plugin.stitch.service.enginepackage, to log the found processors for input and the result of the whole processor pipeline application.
<logger name="com.xebialabs.deployit.plugin.stitch.service.engine" level="debug"/>
If the rule application fails at some point inside the rule, the original input will be returned instead. This will be also logged as a warning, to inform you that this is something not expected.
See Stitch preview