You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Flavel Heyman <Fl...@perficient.com> on 2015/05/14 18:08:24 UTC
Import Root or /jcr:system
****Part 1:
I receive an exception while trying to import the ³/jcr:system² node into
³/³: javax.jcr.ItemExistsException: Node with the same UUID exists:node
/jcr:system
When I run through debug mode the node IDs are not equal causing
Jackrabbit to throw the exception:
existing.getId() = "deadbeef-cafe-babe-cafe-babecafebabe²
id = null
My simple import code:
ByteArrayOutputStream out = new ByteArrayOutputStream();
session.exportSystemView("/jcr:system", out, false, false);
System.out.println("WAIT: "+ new String(out.toByteArray()));
//Insert a breakpoint here to modify data before replacing the current
data, simple test
InputStream in = new ByteArrayInputStream(out.toByteArray());
session.importXML("/", in,
ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
session.save();
Jackrabbit code in SessionImporter (line 377 for Jackrabbit 2.6.5 (my
current version) (also exists for the same line in 2.10.0¹s version)):
if (!(existing.getId().equals(id)
&& (uuidBehavior ==
ImportUUIDBehavior.IMPORT_UUID_COLLISION_REMOVE_EXISTING
|| uuidBehavior ==
ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING))) {
throw new ItemExistsException(
"Node with the same UUID exists:" +
existing);
}
I would venture to say the Node with the same UUID does not exist
(assuming ID is equivalent to the UUID being reference by the errorŠ).
The error description should be a bit different, or add more information.
The XML I¹m trying got import is about 5,624 lines long, but I doubt
people want to receive that in their inbox.
****Part 2:
When I import the ³/jcr:system² node into a subfolder (like /z,
nt:unstructured) it only brings in the 2nd level of children from
³/jcr:system² (jar:versionStorage, jar:activities, jcr:nodeTypes). It
doesn¹t bring in any versions! The export has all the data but the import
is deleting the important information. Some configuration for my current
system:
Repository.OPTION_XML_IMPORT_SUPPORTED is true
In my repository XML I have the following that helps with importing the
ACLs:
<Import>
<ProtectedNodeImporter
class="org.apache.jackrabbit.core.xml.AccessControlImporter"/>
</Import>
By default shouldn¹t Jackrabbit just import everything? Start with being
able to import everything and narrow scope through configuration. At
least then devs would be able to use expected features easily. I would
prefer to just export ³/³ and import into ³/³, but:
javax.jcr.nodetype.ConstraintViolationException: Unexpected node type
{internal}ACL. Should be rep:AccessControl or rep:PrincipalAccessControl.
Sincerely,
-Annoyed I¹m still using this.
Re: Import Root or /jcr:system
Posted by Fabián Mandelbaum <fm...@gmail.com>.
You can always do it programmatically (albeit I do recognize it's a
PITA...), something like this (you'll need a connection to both old and new
repo), in pseudo-code:
while (there's content) {
revhistory = get_revhistory_for_content_on_old_repo();
while (revhistory.hasNext()) {
revision = revhistory.next();
contentToCopy = read_frozen_node_for_rev(revision);
write_on_new_repo_creating_a_new_revision(contentToCopy);
}
}
HTH
On Thu, May 14, 2015 at 5:46 PM, Flavel Heyman <Flavel.Heyman@perficient.com
> wrote:
> I noticed this statement from some random guy on the internet:
> http://www.liferay.com/community/forums/-/message_boards/message/2108515
> excerpt: "Note that the export file will have all your docs and also
> revision history, but there is no way to import back all your revision
> history from an export file (it is not part of the jcr specifications)."
>
> So if that is true then, guess I’m stuck recreating the versions manually,
> *slow clap*. That makes sense.
>
>
> >****Part 1:
> >
> >I receive an exception while trying to import the ³/jcr:system² node into
> >³/³: javax.jcr.ItemExistsException: Node with the same UUID exists:node
> >/jcr:system
> >
> >When I run through debug mode the node IDs are not equal causing
> >Jackrabbit to throw the exception:
> >existing.getId() = "deadbeef-cafe-babe-cafe-babecafebabe²
> >id = null
> >
> >
> >
> >My simple import code:
> >
> >ByteArrayOutputStream out = new ByteArrayOutputStream();
> > session.exportSystemView("/jcr:system", out,
> false, false);
> > System.out.println("WAIT: "+ new
> String(out.toByteArray()));
> >//Insert a breakpoint here to modify data before replacing the current
> >data, simple test
> >
> > InputStream in = new
> ByteArrayInputStream(out.toByteArray());
> > session.importXML("/", in,
> >ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
> > session.save();
> >
> >
> >
> >Jackrabbit code in SessionImporter (line 377 for Jackrabbit 2.6.5 (my
> >current version) (also exists for the same line in 2.10.0¹s version)):
> >
> >if (!(existing.getId().equals(id)
> > && (uuidBehavior ==
> >ImportUUIDBehavior.IMPORT_UUID_COLLISION_REMOVE_EXISTING
> > || uuidBehavior ==
> >ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING))) {
> > throw new ItemExistsException(
> > "Node with the same UUID exists:" +
> >existing);
> > }
> >
> >
> >I would venture to say the Node with the same UUID does not exist
> >(assuming ID is equivalent to the UUID being reference by the errorŠ).
> >The error description should be a bit different, or add more information.
> >The XML I¹m trying got import is about 5,624 lines long, but I doubt
> >people want to receive that in their inbox.
> >
> >****Part 2:
> >
> >When I import the ³/jcr:system² node into a subfolder (like /z,
> >nt:unstructured) it only brings in the 2nd level of children from
> >³/jcr:system² (jar:versionStorage, jar:activities, jcr:nodeTypes). It
> >doesn¹t bring in any versions! The export has all the data but the import
> >is deleting the important information. Some configuration for my current
> >system:
> >Repository.OPTION_XML_IMPORT_SUPPORTED is true
> >
> >In my repository XML I have the following that helps with importing the
> >ACLs:
> ><Import>
> > <ProtectedNodeImporter
> >class="org.apache.jackrabbit.core.xml.AccessControlImporter"/>
> > </Import>
> >
> >
> >
> >By default shouldn¹t Jackrabbit just import everything? Start with being
> >able to import everything and narrow scope through configuration. At
> >least then devs would be able to use expected features easily. I would
> >prefer to just export ³/³ and import into ³/³, but:
> >javax.jcr.nodetype.ConstraintViolationException: Unexpected node type
> >{internal}ACL. Should be rep:AccessControl or rep:PrincipalAccessControl.
> >
> >
> >Sincerely,
> >-Annoyed I¹m still using this.
> >
>
>
--
Fabián Mandelbaum
IS Engineer
Re: Import Root or /jcr:system
Posted by Flavel Heyman <Fl...@perficient.com>.
I noticed this statement from some random guy on the internet:
http://www.liferay.com/community/forums/-/message_boards/message/2108515
excerpt: "Note that the export file will have all your docs and also
revision history, but there is no way to import back all your revision
history from an export file (it is not part of the jcr specifications)."
So if that is true then, guess I’m stuck recreating the versions manually,
*slow clap*. That makes sense.
>****Part 1:
>
>I receive an exception while trying to import the ³/jcr:system² node into
>³/³: javax.jcr.ItemExistsException: Node with the same UUID exists:node
>/jcr:system
>
>When I run through debug mode the node IDs are not equal causing
>Jackrabbit to throw the exception:
>existing.getId() = "deadbeef-cafe-babe-cafe-babecafebabe²
>id = null
>
>
>
>My simple import code:
>
>ByteArrayOutputStream out = new ByteArrayOutputStream();
> session.exportSystemView("/jcr:system", out, false, false);
> System.out.println("WAIT: "+ new String(out.toByteArray()));
>//Insert a breakpoint here to modify data before replacing the current
>data, simple test
>
> InputStream in = new ByteArrayInputStream(out.toByteArray());
> session.importXML("/", in,
>ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
> session.save();
>
>
>
>Jackrabbit code in SessionImporter (line 377 for Jackrabbit 2.6.5 (my
>current version) (also exists for the same line in 2.10.0¹s version)):
>
>if (!(existing.getId().equals(id)
> && (uuidBehavior ==
>ImportUUIDBehavior.IMPORT_UUID_COLLISION_REMOVE_EXISTING
> || uuidBehavior ==
>ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING))) {
> throw new ItemExistsException(
> "Node with the same UUID exists:" +
>existing);
> }
>
>
>I would venture to say the Node with the same UUID does not exist
>(assuming ID is equivalent to the UUID being reference by the errorŠ).
>The error description should be a bit different, or add more information.
>The XML I¹m trying got import is about 5,624 lines long, but I doubt
>people want to receive that in their inbox.
>
>****Part 2:
>
>When I import the ³/jcr:system² node into a subfolder (like /z,
>nt:unstructured) it only brings in the 2nd level of children from
>³/jcr:system² (jar:versionStorage, jar:activities, jcr:nodeTypes). It
>doesn¹t bring in any versions! The export has all the data but the import
>is deleting the important information. Some configuration for my current
>system:
>Repository.OPTION_XML_IMPORT_SUPPORTED is true
>
>In my repository XML I have the following that helps with importing the
>ACLs:
><Import>
> <ProtectedNodeImporter
>class="org.apache.jackrabbit.core.xml.AccessControlImporter"/>
> </Import>
>
>
>
>By default shouldn¹t Jackrabbit just import everything? Start with being
>able to import everything and narrow scope through configuration. At
>least then devs would be able to use expected features easily. I would
>prefer to just export ³/³ and import into ³/³, but:
>javax.jcr.nodetype.ConstraintViolationException: Unexpected node type
>{internal}ACL. Should be rep:AccessControl or rep:PrincipalAccessControl.
>
>
>Sincerely,
>-Annoyed I¹m still using this.
>