David Kennedy wrote:
Is there a set of testcases to drive the WebDAV contrib component of
jackrabbit?
litmus
http://www.webdav.org/neon/litmus/
in order to be able to run the test with default
configuration (which is currently not possible)
i created a new jira issue.
http://issues.apache.org/
[ http://issues.apache.org/jira/browse/JCR-442?page=all ]
Nicolas Toper updated JCR-442:
--
Attachment: patch-backup-090806.txt
Hopefully, this is one of the last patches for this project :)
Everything is working but the importXML method in the VersionManage
Ignore root node when importing through sysView
---
Key: JCR-535
URL: http://issues.apache.org/jira/browse/JCR-535
Project: Jackrabbit
Issue Type: Improvement
Components: core
Hi Jackrabbit Developers,
Could someone have a look at the thread I posted over on the Spring JCR forum.
http://forum.springframework.org/showthread.php?t=27738
Essentially, I am unable to save nodes and then query and find them
within the same session and transaction. One thing to keep in mind
Is there a set of testcases to drive the WebDAV contrib component of
jackrabbit?
David
Hi Tobias,
The issue I have is nothing allow
It's really simpler for me to update all protected nodes, restore the
version history and then switch back to the protection. However to do so, I
don't see any other option than adding a method reregisterBuiltIn in the
NodeTypeManager... I am not sure
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/ -
RepositoryStub fails to load default properties file
Key: JCR-534
URL: http://issues.apache.org/jira/browse/JCR-534
Project: Jackrabbit
Issue Type: Bug
Components: JCR TCK
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,
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:roo
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 s
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
http://issues.apache.org/jira/b
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,
-- Mi
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! h
Hi,
On 8/8/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Also, now that I re-review the code... An s2.save() followed by
s2.logout() after the import will probably solve the issue. :-)
BTW, you should use session.getWorkspace().importXML() to import
content directly into the persistence layer w
Hi,
On 8/8/06, Nicolas <[EMAIL PROTECTED]> wrote:
I have done so. Actually either the bug is in importXML or I am not using
this method correctly
One thing you should do is to use the constats in
javax.jcr.ImportUUIDBehaviour instead of magic numbers, but that's not
likely the cause of your is
Hi Piyush,
This is not implemented yet but should be under the name of incremental
backup :) There is definitely something to work on with the Node Version
History. This should be v2 anyway :)
Nico
On 8/8/06, Piyush Purang <[EMAIL PROTECTED]> wrote:
Hi Nicolas,
> Well you could define a prop
Hi Toby,
Let's say I update 100 times a node, wouldn't this be impratical in the long
run?
On 8/8/06, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:
for restore, you get the relevant versions by
changeset.getReferences() and you can restore the nodes.
regards, toby
On 8/8/06, Piyush Purang <[EM
I have done so. Actually either the bug is in importXML or I am not using
this method correctly
On 8/8/06, Jukka Zitting (JIRA) <[EMAIL PROTECTED]> wrote:
[
http://issues.apache.org/jira/browse/JCR-442?page=comments#action_12426485]
Jukka Zitting commented on JCR-442:
-
what you would do is to create a the 'changeset' nodes seperately, and
every version has a reference to the changeset. eg:
[Changeset] > mix:referenceable
- id (long) mandatory
[File] > nt:file, mix:versionable
- changeset (reference) < Changeset
so, when comitting, you create a new Changeset n
[ http://issues.apache.org/jira/browse/JCR-482?page=all ]
Jukka Zitting reassigned JCR-482:
-
Assignee: Jukka Zitting
> DocViewSaxEventGenerator may generate non-NS-wellformed XML
> ---
>
>
Hi Nicolas,
Well you could define a property for a Global Revision Number with each
commit.
Just having a simple global revision number will not do. We will need
a datastructure like this
grn -> versions of nodes different from last increment to grn (global
revision number)
1 -> /a(1)
2 -> /
[
http://issues.apache.org/jira/browse/JCR-442?page=comments#action_12426485 ]
Jukka Zitting commented on JCR-442:
---
Committed patch-060808-backup.txt in revision 429606. Note that I changed the
Java 5 String.contains() call to String.indexOf()
23 matches
Mail list logo
