 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
2 messages in org.apache.jackrabbit.usersRe: Migrating from DerbyPersistence | Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Migrating from DerbyPersistence | Actions... |
|---|---|---|
| From: | Rich K. (rich...@connectyourcare.com) | |
| Date: | Oct 23, 2007 1:44:34 pm | |
| List: | org.apache.jackrabbit.users | |
I was able to import/export my data using session.exportSystemView() and workspace.importXML() and it was looking pretty good until I attempted to add a new node. When I go to add a new node, we checkin the node itself and when it attempts to checkin the parent node, that is when I get a NPE. This is the line which throws the NPE in AbstractVersionManager String versionName = best.getName().getLocalName(); It looks like if no version was available best would not be set. So when I check the parent node which is failing, parentNode.getBaseBersion().getPredecessors().length returns 0. I am wonder after I run importXML, do I need to do something to initialize the versions?
java.lang.NullPointerException
at
org.apache.jackrabbit.core.version.AbstractVersionManager.calculateCheckinVersionName(AbstractVersionManager.java:440)
at
org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:374)
at
org.apache.jackrabbit.core.version.VersionManagerImpl$2.run(VersionManagerImpl.java:289)
at
org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:564)
at
org.apache.jackrabbit.core.version.VersionManagerImpl.checkin(VersionManagerImpl.java:285)
at
org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:161)
at org.apache.jackrabbit.core.NodeImpl.checkin(NodeImpl.java:3006)
at com.cc.framework.util.NodeUtil.checkin(NodeUtil.java:674)
Rich K. wrote:
We are in the process of trying to setup a jackrabbit cluster and one of the first steps is migrating to a shared database persistence manager. When we first setup our jackrabbit repository, we just went with the default local DerbyPersistenceManager, but now we need to move our data into a new shared persistence storage. We have a mssql server database and I need to move all the content over. I have briefly tried the jackrabbit backup tool without much luck, our custom node types and namespaces seem to be giving it some trouble. If anyone has any experience with migrating repositories, your experiences would be greatly appreciated.
Thanks,
Rich
--
View this message in context:
http://www.nabble.com/Migrating-from-DerbyPersistence-tf4629726.html#a13373229
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.