You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Thierry Ygé (JIRA)" <ji...@apache.org> on 2015/06/17 12:21:00 UTC

[jira] [Created] (JCRVLT-95) Add more detailled in the log about the path / source of an issue to better / quickly remove blocker

Thierry Ygé created JCRVLT-95:
---------------------------------

             Summary: 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)