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.
Hi Nico,
Yes and No.
Backing up changesets is incremental... but classically incremental
backups are periodic and not necessarily on every revision. A very
important distinction.
Cheers
Piyush
On 8/8/06, Nicolas [EMAIL PROTECTED] wrote:
Hi Piyush,
This is not implemented yet but should be
[
http://issues.apache.org/jira/browse/JCR-534?page=comments#action_12426874 ]
Marcel Reutegger commented on JCR-534:
--
Class.getResourceAsStream() has a different semantic than
ClassLoader.getResourceAsStream(). The latter does not modify
the search index is not transactional. i.e. the items are indexed
after the transaction is comitted. that's why you can't find them
unless you commit the transaction.
regards, toby
On 8/8/06, Rasik Pandey [EMAIL PROTECTED] wrote:
Hi Jackrabbit Developers,
Could someone have a look at the
On 8/8/06, Nicolas [EMAIL PROTECTED] wrote:
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
Hi Stefan,
Just out of curiosity, under what circumstances could it be useful to
backup/restore the repository without the version storage? If you're
using versionable nodes, then if you lose the version history you end up
in a right old mess. Is there a usage scenario I'm missing here?
miro
[
http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12426887 ]
Jukka Zitting commented on JCR-535:
---
I don't think we currently implement the IMPORT_UUID_REPLACE_EXISTING behaviour
for jcr:root as specified in section 7.3.8.
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
[
http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12426888 ]
Stefan Guggisberg commented on JCR-535:
---
I don't think we currently implement the IMPORT_UUID_REPLACE_EXISTING
behaviour
for jcr:root as specified in
[ http://issues.apache.org/jira/browse/JCR-535?page=all ]
Stefan Guggisberg updated JCR-535:
--
Comment: was deleted
Ignore root node when importing through sysView
---
Key: JCR-535
[
http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12426891 ]
Stefan Guggisberg commented on JCR-535:
---
you're right, i reread section 7.3.8 and agree with you that we currently don't
handle
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
[
http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12426892 ]
Jukka Zitting commented on JCR-535:
---
no, it wouldn't. we deliberatly don't allow to replace the root node.
/jcr:system e.g. is protected,
and for a good reason
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
Ok this makes sense. Thanks guys.
Regards,
Rus Pandey
On 8/9/06, Marcel Reutegger [EMAIL PROTECTED] wrote:
Hi,
A query is always executed against the persistent workspace content
the session is connected to. Which means it does not take un-committed
content into account.
The spec says:
spec
Tobias,
Are you sure no modifications are done (update of the UUID for instance)? I
have tried the way you described and it didn't seem to work properly. I had
no error but when I reexport the subtree, its weight was half on the
original.
I had add a look at the JSR170 spec on this and it seems
On 8/9/06, Tobias Bocanegra [EMAIL PROTECTED] wrote:
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
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
Session leak in API test cases
--
Key: JCR-536
URL: http://issues.apache.org/jira/browse/JCR-536
Project: Jackrabbit
Issue Type: Bug
Components: JCR TCK
Reporter: Julian Reschke
[ http://issues.apache.org/jira/browse/JCR-533?page=all ]
Stefan Guggisberg updated JCR-533:
--
Summary: failing Node.lock() might leave inconsistent transient state
(was: refresh(false) don't remove falied lock from transiente session)
the real issue
No I am writing this importer and wondering if there is a better way :)
On 8/9/06, Tobias Bocanegra [EMAIL PROTECTED] wrote:
you've written an importer that operates directly on the local item
state manager of the versioning virtual workspace?
--
-
[ http://issues.apache.org/jira/browse/JCR-533?page=all ]
Stefan Guggisberg resolved JCR-533.
---
Resolution: Fixed
fixed in svn rev. 430067
thanks for reporting this issue!
failing Node.lock() might leave inconsistent transient state
All,
I have configured my Jackrabbit repository using Spring Module 0.5
In a single transaction, I have to do some operation in database and
jackrabbit repository as well.
I am using Spring's HibernateDAO for database access and JcrDAOSupport for
accessing jackrabbit repository.
How to
All,
What are all the functionalities supported by this
jackrabbit-server-1.0.1.war distribution.
By deploying this war file, can we perform checkin/checkout from webdav
client.
Otherwise is this only a reference implementation ?
Regards,
Shan
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
[ http://issues.apache.org/jira/browse/JCR-536?page=all ]
Julian Reschke updated JCR-536:
---
Attachment: JCR-536.diff.txt
Proposed Patch.
Session leak in API test cases
--
Key: JCR-536
URL:
Hi,
as far as I understand, the TCK is supposed to run against an L1 (==
read only) repository. For instance, the property tests certainly try to
find testable properties without having to create them...
Now, AbstractJCRTest.cleanUpTestRoot fails due to
UnsupportedOperationExceptions over
[
http://issues.apache.org/jira/browse/JCR-533?page=comments#action_12426970 ]
Paco Avila commented on JCR-533:
Ok, Node.lock() when fails don't save state on transient session. But why? When
I try a node modification on a node where I have no
[
http://issues.apache.org/jira/browse/JCR-533?page=comments#action_12426971 ]
Paco Avila commented on JCR-533:
... Continued. A lock is a node modification adding some properties. So, if I
make a lock and these properties are added in my
Julian Reschke wrote:
as far as I understand, the TCK is supposed to run against an L1 (==
read only) repository. For instance, the property tests certainly try to
find testable properties without having to create them...
Now, AbstractJCRTest.cleanUpTestRoot fails due to
[ http://issues.apache.org/jira/browse/JCR-536?page=all ]
Marcel Reutegger resolved JCR-536.
--
Fix Version/s: 1.1
Resolution: Fixed
Fixed as proposed.
svn revision: 430101
Thank you for reporting this issue.
Session leak in API test cases
Failure to remove a versionable node
Key: JCR-537
URL: http://issues.apache.org/jira/browse/JCR-537
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.1
Reporter: Florent Guillaume
Hi Robert,
[...]
one of the main reasons why i want to use webDAV is that it's RESTful.
IMAP and POP3 both suck for the problems i'm interested in because
they are not.
Yes. But I just want to create a RESTful 'view' at IMAP / POP3.
Nothing to edit / change, only view. :) I think that is
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
40 matches
Mail list logo
