You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Nicolas <nt...@gmail.com> on 2006/08/08 15:31:34 UTC
can't Import a system view using ImportXML
Hi,
When I try to import a whole workspace, here is the exception thrown:
/jcr:root: mandatory child node {http://www.jcp.org/jcr/1.0}system does not
exist. I don't understand why it happens and how to correct it: the root
node has children...
Do you have any idea?
Thanks a lot,
Nico
my blog! http://www.deviant-abstraction.net !!
Re: can't Import a system view using ImportXML
Posted by Florent Guillaume <fg...@nuxeo.com>.
Nicolas wrote:
> Hi Florent,
>> I would definitely like to see the root node referenceable, it
>> would avoid special casing it in some of my code.
>
> How do you manage it for now?
By special-casing failures of getUUID in my application code.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
Hi Florent,
How do you manage it for now?
BR,
Nico
my blog! http://www.deviant-abstraction.net !!
Re: can't Import a system view using ImportXML
Posted by Florent Guillaume <fg...@nuxeo.com>.
Jukka Zitting wrote:
> Another fact is that currently rep:root is not mix:referenceable, so
> the root node doesn't expose the jcr:uuid property and thus there is
> no way to actually invoke the special jcr:root processing rules
> specified by JSR 170.
>
> So for now the best approach is to use a custom importer for the
> restore tool, but we might still want to consider making the root node
> referenceable and implementing the proposed jcr:root handling in
> import.
I would definitely like to see the root node referenceable, it would
avoid special casing it in some of my code.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Re: can't Import a system view using ImportXML
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/9/06, Nicolas <nt...@gmail.com> wrote:
> What I don't understand is I find the code in the WorkspaceImporter in the
> protected NodeState resolveUUIDConflict method.
>
> Here is an excerpt:
> itemOps.checkRemoveNode(conflicting,
> BatchedItemOperations.CHECK_ACCESS
> | BatchedItemOperations.CHECK_LOCK
> | BatchedItemOperations.CHECK_VERSIONING
> | BatchedItemOperations.CHECK_CONSTRAINTS);
> // do remove conflicting (recursive)
> itemOps.removeNodeState(conflicting););
The problem with that is that we don't want to *remove* the root node,
just replace all its unprotected content.
As further discussed on IM, there are two other related issues. One is
the fact that currently the code that handles REPLACE_EXISTING falls
back to throwing a RepositoryException when handling the root node.
This seems to be in line with allowed behaviour specified in JSR 170.
Another fact is that currently rep:root is not mix:referenceable, so
the root node doesn't expose the jcr:uuid property and thus there is
no way to actually invoke the special jcr:root processing rules
specified by JSR 170.
So for now the best approach is to use a custom importer for the
restore tool, but we might still want to consider making the root node
referenceable and implementing the proposed jcr:root handling in
import.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
Sorry to post everything in several mail. Actually the error in importing
from the sysView is in this validation code (in ItemValidator):
// mandatory child nodes
NodeDef[] cnda = entPrimaryAndMixins.getMandatoryNodeDefs();
for (int i = 0; i < cnda.length; i++) {
NodeDef cnd = cnda[i];
if (!nodeState.hasChildNodeEntry(cnd.getName())) {
String msg = safeGetJCRPath(nodeState.getNodeId())
+ ": mandatory child node " + cnd.getName()
+ " does not exist";
log.debug(msg);
throw new ConstraintViolationException(msg);
}
}
}
The issue here is {internal}root (is there a difference with jcr:root?)
doesn't have the mandatory child nodes... Which is true according to the
sysView XML.
For reference, the exception I got is:
Exception in thread "main" javax.jcr.nodetype.ConstraintViolationException:
/jcr:root: mandatory child node {http://www.jcp.org/jcr/1.0}system does not
exist
at org.apache.jackrabbit.core.ItemValidator.validate(ItemValidator.java
:144)
at org.apache.jackrabbit.core.xml.WorkspaceImporter.endNode(
WorkspaceImporter.java:538)
at org.apache.jackrabbit.core.xml.SysViewImportHandler.processNode(
SysViewImportHandler.java:95)
at org.apache.jackrabbit.core.xml.SysViewImportHandler.endElement(
SysViewImportHandler.java:233)
at org.apache.jackrabbit.core.xml.ImportHandler.endElement(
ImportHandler.java:210)
And so on...
I would propose to keep "my quick hack", since if I understand things
correctly we *do* have to skip the root node import.
What do you think?
Nicolas
On 8/9/06, Nicolas <nt...@gmail.com> wrote:
>
> Jukka,
>
> What I don't understand is I find the code in the WorkspaceImporter in the
> protected NodeState resolveUUIDConflict method.
>
> Here is an excerpt:
> itemOps.checkRemoveNode(conflicting,
> BatchedItemOperations.CHECK_ACCESS
> | BatchedItemOperations.CHECK_LOCK
> | BatchedItemOperations.CHECK_VERSIONING
> | BatchedItemOperations.CHECK_CONSTRAINTS );
> // do remove conflicting (recursive)
> itemOps.removeNodeState(conflicting););
>
> Nicolas
>
> On 8/9/06, Jukka Zitting < jukka.zitting@gmail.com> wrote:
>
> > Hi,
> >
> > On 8/9/06, Stefan Guggisberg <st...@gmail.com> wrote:
> > > we should IMO support IMPORT_UUID_COLLISION_REPLACE_EXISTING
> > > for jcr:root properly rather than doing shortterm hacks.
> >
> > Agreed. I think the correct implementation would be something like the
> > following:
> >
> > if (REPLACE_EXISTING and jcr:uuid matches an existing node) {
> > find the target node
> > foreach (target property and child node) {
> > if (!protected) {
> > remove();
> > }
> > }
> > import to target
> > }
> >
> > This would also take care of the jcr:system case quite naturally.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > --
> > Yukatan - http://yukatan.fi/ - info@yukatan.fi
> > Software craftsmanship, JCR consulting, and Java development
> >
>
>
>
> --
> a+
>
> Nico
> my blog! http://www.deviant-abstraction.net !!
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
Jukka,
What I don't understand is I find the code in the WorkspaceImporter in the
protected NodeState resolveUUIDConflict method.
Here is an excerpt:
itemOps.checkRemoveNode(conflicting,
BatchedItemOperations.CHECK_ACCESS
| BatchedItemOperations.CHECK_LOCK
| BatchedItemOperations.CHECK_VERSIONING
| BatchedItemOperations.CHECK_CONSTRAINTS);
// do remove conflicting (recursive)
itemOps.removeNodeState(conflicting););
Nicolas
On 8/9/06, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 8/9/06, Stefan Guggisberg <st...@gmail.com> wrote:
> > we should IMO support IMPORT_UUID_COLLISION_REPLACE_EXISTING
> > for jcr:root properly rather than doing shortterm hacks.
>
> Agreed. I think the correct implementation would be something like the
> following:
>
> if (REPLACE_EXISTING and jcr:uuid matches an existing node) {
> find the target node
> foreach (target property and child node) {
> if (!protected) {
> remove();
> }
> }
> import to target
> }
>
> This would also take care of the jcr:system case quite naturally.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
I am asking this because in the WorkspaceImporter class we have this for
REPLACE_EXISTING:
NodeId parentId = conflicting.getParentId();
if (parentId == null) {
String msg = "root node cannot be replaced";
log.debug(msg);
throw new RepositoryException(msg);
}
BR
Nico
my blog! http://www.deviant-abstraction.net !!
On 8/9/06, Tobias Bocanegra <to...@day.com> wrote:
>
> no jcr:root is not protected, just some nodes in the jcr:system:
>
> [rep:system]
> orderable
> + jcr:versionStorage (rep:versionStorage) = rep:versionStorage
> mandatory protected abort
> + jcr:nodeTypes (rep:nodeTypes) = rep:nodeTypes mandatory protected
> abort
> + * (nt:base) = nt:unstructured multiple ignore
>
> regards, toby
>
>
>
>
Re: can't Import a system view using ImportXML
Posted by Tobias Bocanegra <to...@day.com>.
no jcr:root is not protected, just some nodes in the jcr:system:
[rep:system]
orderable
+ jcr:versionStorage (rep:versionStorage) = rep:versionStorage
mandatory protected abort
+ jcr:nodeTypes (rep:nodeTypes) = rep:nodeTypes mandatory protected abort
+ * (nt:base) = nt:unstructured multiple ignore
regards, toby
On 8/9/06, Nicolas <nt...@gmail.com> wrote:
> Hi,
>
> I understand but isn't jcr:root protected? We won't change the UUID as
> specified in the spec.
>
> Another issue: the pseudo-code you have written earlier should be in
> WorkspaceImporter? Am I correct?
>
> BR
> Nico
> my blog! http://www.deviant-abstraction.net !!
>
> On 8/9/06, Jukka Zitting <ju...@gmail.com> wrote:
> >
> > Hi,
> >
> > On 8/9/06, Nicolas <nt...@gmail.com> wrote:
> > > What would happen to jcr:system if we delete jcr:root and then replace
> > it?
> >
> > I think the best way to implement the REPLACE_EXISTING support is not
> > to actually "replace" the node, but to remove all unprotected
> > properties and child nodes, and to then recreate the properties and
> > child nodes from the import XML. Since protected child nodes won't be
> > affected, jcr:system will not be overridden.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > --
> > Yukatan - http://yukatan.fi/ - info@yukatan.fi
> > Software craftsmanship, JCR consulting, and Java development
> >
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
Hi,
I understand but isn't jcr:root protected? We won't change the UUID as
specified in the spec.
Another issue: the pseudo-code you have written earlier should be in
WorkspaceImporter? Am I correct?
BR
Nico
my blog! http://www.deviant-abstraction.net !!
On 8/9/06, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 8/9/06, Nicolas <nt...@gmail.com> wrote:
> > What would happen to jcr:system if we delete jcr:root and then replace
> it?
>
> I think the best way to implement the REPLACE_EXISTING support is not
> to actually "replace" the node, but to remove all unprotected
> properties and child nodes, and to then recreate the properties and
> child nodes from the import XML. Since protected child nodes won't be
> affected, jcr:system will not be overridden.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
Re: can't Import a system view using ImportXML
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/9/06, Nicolas <nt...@gmail.com> wrote:
> What would happen to jcr:system if we delete jcr:root and then replace it?
I think the best way to implement the REPLACE_EXISTING support is not
to actually "replace" the node, but to remove all unprotected
properties and child nodes, and to then recreate the properties and
child nodes from the import XML. Since protected child nodes won't be
affected, jcr:system will not be overridden.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
Jukka,
What would happen to jcr:system if we delete jcr:root and then replace it?
On 8/9/06, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 8/9/06, Stefan Guggisberg <st...@gmail.com> wrote:
> > we should IMO support IMPORT_UUID_COLLISION_REPLACE_EXISTING
> > for jcr:root properly rather than doing shortterm hacks.
>
> Agreed. I think the correct implementation would be something like the
> following:
>
> if (REPLACE_EXISTING and jcr:uuid matches an existing node) {
> find the target node
> foreach (target property and child node) {
> if (!protected) {
> remove();
> }
> }
> import to target
> }
>
> This would also take care of the jcr:system case quite naturally.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: can't Import a system view using ImportXML
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/9/06, Stefan Guggisberg <st...@gmail.com> wrote:
> we should IMO support IMPORT_UUID_COLLISION_REPLACE_EXISTING
> for jcr:root properly rather than doing shortterm hacks.
Agreed. I think the correct implementation would be something like the
following:
if (REPLACE_EXISTING and jcr:uuid matches an existing node) {
find the target node
foreach (target property and child node) {
if (!protected) {
remove();
}
}
import to target
}
This would also take care of the jcr:system case quite naturally.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: can't Import a system view using ImportXML
Posted by Stefan Guggisberg <st...@gmail.com>.
On 8/9/06, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 8/9/06, Stefan Guggisberg <st...@gmail.com> wrote:
> > i don't agree. that's not how importXML is spec'ed.
>
> As mentioned in the Jira issue, section 7.3.8 of the JSR 170 spec
> specifies special handling for jcr:root during import with
> IMPORT_UUID_COLLISION_REPLACE_EXISTING.
i was wrong and you're absolutely right, sorry.
we should IMO support IMPORT_UUID_COLLISION_REPLACE_EXISTING
for jcr:root properly rather than doing shortterm hacks.
cheers
stefan
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
Re: can't Import a system view using ImportXML
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/9/06, Stefan Guggisberg <st...@gmail.com> wrote:
> i don't agree. that's not how importXML is spec'ed.
As mentioned in the Jira issue, section 7.3.8 of the JSR 170 spec
specifies special handling for jcr:root during import with
IMPORT_UUID_COLLISION_REPLACE_EXISTING.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: can't Import a system view using ImportXML
Posted by Stefan Guggisberg <st...@gmail.com>.
On 8/8/06, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 8/8/06, Nicolas <nt...@gmail.com> wrote:
> > When I try to import a whole workspace, here is the exception thrown:
> > /jcr:root: mandatory child node {http://www.jcp.org/jcr/1.0}system does not
> > exist. I don't understand why it happens and how to correct it: the root
> > node has children...
>
> It seems that the importer is trying to recreate the root node. We
> should probably add special handling of jcr:root in the importer code,
> so that importing "<foo/>" and "<jcr:root><foo/></jcr:root>" (or the
> equivalent system view) under the root node should both result in the
> creation of a "foo" node just below the root node.
i don't agree. that's not how importXML is spec'ed.
note that the JCR importXML methods are not suitable for restoring
system managed data.
cheers
stefan
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
Re: can't Import a system view using ImportXML
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/8/06, Nicolas <nt...@gmail.com> wrote:
> It's done. I will patch it later. Basically if a node in the WspImporter is
> root, I skip it (but process the namespace still)
Great, thanks. You can file the patch as a separate Jira issue.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
It's done. I will patch it later. Basically if a node in the WspImporter is
root, I skip it (but process the namespace still)
On 8/8/06, Nicolas <nt...@gmail.com> wrote:
>
> Hi,
>
> I agree on this. So basically, I should add in core a test to skip the
> storage of jcr:root tag?
>
> Nicolas
>
>
> On 8/8/06, Jukka Zitting < jukka.zitting@gmail.com> wrote:
> >
> > Hi,
> >
> > On 8/8/06, Nicolas < ntoper@gmail.com> wrote:
> > > When I try to import a whole workspace, here is the exception thrown:
> > > /jcr:root: mandatory child node {http://www.jcp.org/jcr/1.0}system
> > <http://www.jcp.org/jcr/1.0%7Dsystem> does not
> > > exist. I don't understand why it happens and how to correct it: the
> > root
> > > node has children...
> >
> > It seems that the importer is trying to recreate the root node. We
> > should probably add special handling of jcr:root in the importer code,
> > so that importing "<foo/>" and "<jcr:root><foo/></jcr:root>" (or the
> > equivalent system view) under the root node should both result in the
> > creation of a "foo" node just below the root node.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > --
> > Yukatan - http://yukatan.fi/ - info@yukatan.fi
> > Software craftsmanship, JCR consulting, and Java development
> >
>
>
>
> --
> a+
>
> Nico
> my blog! http://www.deviant-abstraction.net !!
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
Hi,
I agree on this. So basically, I should add in core a test to skip the
storage of jcr:root tag?
Nicolas
On 8/8/06, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 8/8/06, Nicolas <nt...@gmail.com> wrote:
> > When I try to import a whole workspace, here is the exception thrown:
> > /jcr:root: mandatory child node {http://www.jcp.org/jcr/1.0}system does
> not
> > exist. I don't understand why it happens and how to correct it: the root
> > node has children...
>
> It seems that the importer is trying to recreate the root node. We
> should probably add special handling of jcr:root in the importer code,
> so that importing "<foo/>" and "<jcr:root><foo/></jcr:root>" (or the
> equivalent system view) under the root node should both result in the
> creation of a "foo" node just below the root node.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: can't Import a system view using ImportXML
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/8/06, Nicolas <nt...@gmail.com> wrote:
> When I try to import a whole workspace, here is the exception thrown:
> /jcr:root: mandatory child node {http://www.jcp.org/jcr/1.0}system does not
> exist. I don't understand why it happens and how to correct it: the root
> node has children...
It seems that the importer is trying to recreate the root node. We
should probably add special handling of jcr:root in the importer code,
so that importing "<foo/>" and "<jcr:root><foo/></jcr:root>" (or the
equivalent system view) under the root node should both result in the
creation of a "foo" node just below the root node.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: can't Import a system view using ImportXML
Posted by Nicolas <nt...@gmail.com>.
No I don't think it's the same ;)
I don't export /jcr:system when backuping (I use a special exporter for
this).
Nicolas
On 8/8/06, Daglian, Michael (IT) <Mi...@morganstanley.com> wrote:
>
> Hello Nicolas,
>
> This is expected behavior and has come up previously. Please see
> http://issues.apache.org/jira/browse/JCR-323?page=all for Stefan's
> explanation and suggested workaround (which I am not sure applies to the
> use case of the backup tool of course). Hope that helps!
>
> Best Regards,
>
> -- Mike
>
> > -----Original Message-----
> > From: Nicolas [mailto:ntoper@gmail.com]
> > Sent: Tuesday, August 08, 2006 9:32 AM
> > To: dev@jackrabbit.apache.org
> > Subject: can't Import a system view using ImportXML
> >
> > Hi,
> >
> > When I try to import a whole workspace, here is the exception thrown:
> > /jcr:root: mandatory child node
> > {http://www.jcp.org/jcr/1.0}system does not exist. I don't
> > understand why it happens and how to correct it: the root
> > node has children...
> >
> > Do you have any idea?
> >
> > Thanks a lot,
> > Nico
> > my blog! http://www.deviant-abstraction.net !!
> >
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
RE: can't Import a system view using ImportXML
Posted by "Daglian, Michael (IT)" <Mi...@morganstanley.com>.
Hello Nicolas,
This is expected behavior and has come up previously. Please see
http://issues.apache.org/jira/browse/JCR-323?page=all for Stefan's
explanation and suggested workaround (which I am not sure applies to the
use case of the backup tool of course). Hope that helps!
Best Regards,
-- Mike
> -----Original Message-----
> From: Nicolas [mailto:ntoper@gmail.com]
> Sent: Tuesday, August 08, 2006 9:32 AM
> To: dev@jackrabbit.apache.org
> Subject: can't Import a system view using ImportXML
>
> Hi,
>
> When I try to import a whole workspace, here is the exception thrown:
> /jcr:root: mandatory child node
> {http://www.jcp.org/jcr/1.0}system does not exist. I don't
> understand why it happens and how to correct it: the root
> node has children...
>
> Do you have any idea?
>
> Thanks a lot,
> Nico
> my blog! http://www.deviant-abstraction.net !!
>
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.