You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "Rich K." <ri...@connectyourcare.com> on 2007/10/15 21:15:57 UTC

Migrating from DerbyPersistence

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#a13219791
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Re: Migrating from DerbyPersistence

Posted by "Rich K." <ri...@connectyourcare.com>.
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.