On 8/8/06, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 8/8/06, Nicolas [EMAIL PROTECTED] 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
Hi,
On 8/9/06, Stefan Guggisberg [EMAIL PROTECTED] 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
On 8/9/06, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 8/9/06, Stefan Guggisberg [EMAIL PROTECTED] 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
Hi,
On 8/9/06, Stefan Guggisberg [EMAIL PROTECTED] 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
Jukka,
What would happen to jcr:system if we delete jcr:root and then replace it?
On 8/9/06, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 8/9/06, Stefan Guggisberg [EMAIL PROTECTED] wrote:
we should IMO support IMPORT_UUID_COLLISION_REPLACE_EXISTING
for jcr:root properly rather than doing
Hi,
On 8/9/06, Nicolas [EMAIL PROTECTED] 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
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 [EMAIL
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
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
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
Hi,
On 8/9/06, Nicolas [EMAIL PROTECTED] 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
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
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,
--
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) [EMAIL PROTECTED] wrote:
Hello Nicolas,
This is expected behavior and has come up previously. Please see
Hi,
On 8/8/06, Nicolas [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
Hi,
On 8/8/06, Nicolas [EMAIL PROTECTED] wrote:
When I try to import a whole workspace, here is the exception thrown:
/jcr:root:
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 [EMAIL PROTECTED] 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,
Hi,
On 8/8/06, Nicolas [EMAIL PROTECTED] 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/ -
18 matches
Mail list logo
