Add more detailled in the log about the path / source of an issue to better / quickly remove blocker

In a recent use case, following stack trace could be seen on a failing RCP task.

16.06.2015 09:12:04.424 ERROR [Vault RCP Task - 9553e90f-8304-4a99-8c37-526e84ae2dea] org.apache.jackrabbit.spi2davex.RepositoryServiceImpl Internal error while retrieving NodeInf
o.
java.io.IOException: '^M' not allowed in name
at org.apache.jackrabbit.spi2davex.ItemInfoJsonHandler.key(ItemInfoJSONHandler.java:205)
at org.apache.jackrabbit.commons.json.JsonParser.parse(JsonParser.java:108)
at org.apache.jackrabbit.commons.json.JsonParser.parse(JsonParser.java:73)
at org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getItemInfos(RepositoryServiceImpl.java:365)
at org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:93)
at org.apache.jackrabbit.jcr2spi.state.TransientISFactory.createNodeState(TransientISFactory.java:97)
at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.doResolve(NodeEntryImpl.java:990)
at org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.resolve(HierarchyEntryImpl.java:134)
at org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.getItemState(HierarchyEntryImpl.java:253)
at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.getItemState(NodeEntryImpl.java:71)
at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.getNodeState(NodeEntryImpl.java:363)
at org.apache.jackrabbit.jcr2spi.state.ItemState.getParent(ItemState.java:213)
at org.apache.jackrabbit.jcr2spi.state.NodeState.retrieveDefinition(NodeState.java:465)
at org.apache.jackrabbit.jcr2spi.state.NodeState.getDefinition(NodeState.java:316)
at org.apache.jackrabbit.jcr2spi.NodeImpl.getDefinition(NodeImpl.java:857)
at org.apache.jackrabbit.vault.util.RepositoryCopier.copy(RepositoryCopier.java:314)
at org.apache.jackrabbit.vault.util.RepositoryCopier.copy(RepositoryCopier.java:277)
at org.apache.jackrabbit.vault.rcp.impl.RcpTask.run(RcpTask.java:200)
at java.lang.Thread.run(Thread.java:745)

It would have been good to have the information about the exact node path where this issue occurred. Maybe some additional logging message could be added to be more precise on which working item it failed.

We found the content tree that the offending content was in and removed it from the server. Once it was removed we could once again migrate the content from our production server.

Would have been nice if the logging when in trace actually logged where it was in processing the tree.