[
https://issues.apache.org/jira/browse/JCRVLT-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590166#comment-14590166
]
Tobias Bocanegra commented on JCRVLT-95:
----------------------------------------
when executing vlt-rcp on the command line, you can turn on jcr logging:
{noformat}
$ vlt -Xjcrlog
Description:
Enables and controls JcrLog. JcrLog dumps all calls through the
JCR API to a file and/or stdout.
Options:
sysout enable logging to the stdout
return enable logging of return values
caller enable logging of the caller
exception enable logging of exceptions
stream enable logging of streams
file=<file> log to the specified file
Example:
-Xjcrlog:sysout,retrun,file=my.log
{noformat}
> Add more detailled in the log about the path / source of an issue to better /
> quickly remove blocker
> ----------------------------------------------------------------------------------------------------
>
> Key: JCRVLT-95
> URL: https://issues.apache.org/jira/browse/JCRVLT-95
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: RCP
> Affects Versions: 3.1.18
> Reporter: Thierry Ygé
>
> 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.
> {quote}
> 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.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
