[jira] Commented: (JCR-332) maven2 pom contribution

[ http://issues.apache.org/jira/browse/JCR-332?page=comments#action_12426153 ] Jukka Zitting commented on JCR-332: --- Thanks again, Chistoph! I committed the RMI compilation change in revision 429258. I digged a bit deeper on the multiline desc

[jira] Closed: (JCR-483) Lock tokens reains in session after unlock

[ http://issues.apache.org/jira/browse/JCR-483?page=all ] Paco Avila closed JCR-483. -- Ok, now it works. Thanks! > Lock tokens reains in session after unlock > -- > > Key: JCR-483 > URL: http:/

[jira] Commented: (JCR-505) TCK: AbstractJCRTest fails if setUp/tearDown cannot remove children of test node

[ http://issues.apache.org/jira/browse/JCR-505?page=comments#action_12426156 ] Marcel Reutegger commented on JCR-505: -- I agree. I've changed the cleanUpTestRoot() method and added a try catch clause which consumes a ConstraintViolationExce

[jira] Created: (JCR-533) refresh(false) don't remove falied lock from transiente session

refresh(false) don't remove falied lock from transiente session --- Key: JCR-533 URL: http://issues.apache.org/jira/browse/JCR-533 Project: Jackrabbit Issue Type: Bug Comp

[jira] Resolved: (JCR-531) TCK: OrderByMultiTypeTest doesn't respect nodetype configuration property

[ http://issues.apache.org/jira/browse/JCR-531?page=all ] Marcel Reutegger resolved JCR-531. -- Fix Version/s: 1.1 Resolution: Fixed Changed test case as proposed. svn revision: 429267 Thank you for reporting this issue. > TCK: OrderByMultiTypeT

Re: AbstractSAXEventGenerator query

On 8/6/06, Jack Park <[EMAIL PROTECTED]> wrote: What might be the objections raised to turning this abstract class into a public one (in future distributions) for purposes of allowing others to write exporters in jackrabbit applications that have different behaviors? That would be done by externa

Re: AbstractSAXEventGenerator query

Hi, On 8/7/06, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: AbstractSAXEventGenerator is a core class. i try to avoid making internal jackrabbit classes public in order to discourage their use from outside of the core package. core classes should not be externally referenced as they might change

[jira] Reopened: (JCR-483) Lock tokens reains in session after unlock

[ http://issues.apache.org/jira/browse/JCR-483?page=all ] Jukka Zitting reopened JCR-483: --- Reopened to fix the version tags. > Lock tokens reains in session after unlock > -- > > Key: JCR-48

[jira] Updated: (JCR-483) Lock tokens reains in session after unlock

[ http://issues.apache.org/jira/browse/JCR-483?page=all ] Jukka Zitting updated JCR-483: -- Fix Version/s: 1.1 Affects Version/s: 0.9 1.0 > Lock tokens reains in session after unlock > --

[jira] Resolved: (JCR-483) Lock tokens reains in session after unlock

[ http://issues.apache.org/jira/browse/JCR-483?page=all ] Jukka Zitting resolved JCR-483. --- Resolution: Fixed > Lock tokens reains in session after unlock > -- > > Key: JCR-483 > URL: h

[jira] Updated: (JCR-533) refresh(false) don't remove falied lock from transiente session

[ http://issues.apache.org/jira/browse/JCR-533?page=all ] Paco Avila updated JCR-533: --- Attachment: DummyLockAccessDenied.java Test program > refresh(false) don't remove falied lock from transiente session >

[jira] Updated: (JCR-533) refresh(false) don't remove falied lock from transiente session

[ http://issues.apache.org/jira/browse/JCR-533?page=all ] Paco Avila updated JCR-533: --- Attachment: MyAccessManagerLockAccessDenied.java Test AccessManager implementation for this issue > refresh(false) don't remove falied lock from transiente session > --

Re: Issue when restoring the Node version history

Hi, I have encountered an issue when restoring the node version history. As you know it is part of the shared subtree /jcr:system. All the versioning is contained within /jcr:system/jcr:versionStorage. All those nodes are protected. I have backupped the data by using the exportXML method of Sessi

[jira] Commented: (JCR-332) maven2 pom contribution

[ http://issues.apache.org/jira/browse/JCR-332?page=comments#action_12426170 ] Christoph Kiehl commented on JCR-332: - Jukka, I my case the problem were the newlines of the multiline description. Plexus archiver adds a line break after a cer

Re: JSR170 for Source code Version control system

On 8/7/06, Hariharasudhan.D Dhakshinamoorthy <[EMAIL PROTECTED]> wrote: Hi ! iam not sure if this is the right place for this , iam planning to write the JSR170 api for CVS , how can jackrabit help me any tips / suggestions will be appreciated thanks haris :-) i would write a webdav server

Re: Issue when restoring the Node version history

Why wouldn't it work if we bypass the VersionManager? BR Nico my blog! http://www.deviant-abstraction.net !!

[jira] Commented: (JCR-332) maven2 pom contribution

[ http://issues.apache.org/jira/browse/JCR-332?page=comments#action_12426177 ] Jukka Zitting commented on JCR-332: --- > I my case the problem were the newlines of the multiline description. Ah, bugger. OK, I think that's reason enough to apply

Re: Issue when restoring the Node version history

Why wouldn't it work if we bypass the VersionManager? you would need to flush all the caches. but since you probably restart the repo anyways after restore, this might not be a problem. regards, toby -- -< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Mana

Issue when restoring the Node version history

-- Forwarded message -- From: Nicolas <[EMAIL PROTECTED]> Date: Aug 7, 2006 11:33 AM Subject: Re: Issue when restoring the Node version history To: [EMAIL PROTECTED] Yes that's why I thought :) I do think however, adding an import method to the VersionManager is way more elegant.

Re: JSR170 for Source code Version control system

Hi Toby, Subversion uses Global Revision Numbers but Jackrabbit supports a version for each versionable item so isn't there a mismatch? What I'd really like to see is some way of building and exporting "change sets" that would make backup and restore of content easy. Cheers Piyush On 8/7/06,

Re: using jackrabbit to store email with meta-data

Hi Robert, [...] >> Additionally I am interested in a good XML format for msgs. [...] > i suspect that the hardest part of the problem will be defining > exactly that good means in this context. any initial thoughts? We've collected some resources here:

Re: JSR170 for Source code Version control system

Hi Piyush, Well you could define a property for a Global Revision Number with each commit. Can you please elaborate on your change sets ideas: I am working on the backup tool. The first version is nearly over and I am gathering feedback and comment to lay out spec for a second version. Nicolas

[jira] Resolved: (JCR-468) Item.isSame() may return true for 2 nodes from different workspaces.

[ http://issues.apache.org/jira/browse/JCR-468?page=all ] Stefan Guggisberg resolved JCR-468. --- Resolution: Fixed fixed in svn r429293 > Item.isSame() may return true for 2 nodes from different workspaces. >

Re: AbstractSAXEventGenerator query

Thanks! What I have done in the mean time is simply clone code from two classes, AbstractSAXEventGenerator and the class that extends it and, from that, written my own exporter that works fine! I don't have the results in front of me, and perhaps I should try another export just to prove it

Re: JSR170 for Source code Version control system

Iam thinking that jackrabit is a RMI version of the JSR 170 API .., please correct me if am wrong :) On 8/7/06, Nicolas <[EMAIL PROTECTED]> wrote: Hi Piyush, Well you could define a property for a Global Revision Number with each commit. Can you please elaborate on your change sets ideas:

Re: JSR170 for Source code Version control system

You are wrong :) Jackrabbit contains a RMI version of the JSR170 but also a full implementation of the JCR170. Nicolas On 8/7/06, Hariharasudhan.D Dhakshinamoorthy <[EMAIL PROTECTED]> wrote: Iam thinking that jackrabit is a RMI version of the JSR 170 API .., please correct me if am wrong :)

Re: JSR170 for Source code Version control system

Thanks :-) On 8/7/06, Nicolas <[EMAIL PROTECTED]> wrote: You are wrong :) Jackrabbit contains a RMI version of the JSR170 but also a full implementation of the JCR170. Nicolas On 8/7/06, Hariharasudhan.D Dhakshinamoorthy <[EMAIL PROTECTED]> wrote: > > Iam thinking that jackrabit is a RMI ver

Re: JSR170 for Source code Version control system

Hi, Here is a suggestion. Jackrabbit is great tool to hold repositories. Node types are a great way to extend the basic concepts of jackrabbit. What if we all worked on this implementation where jackrabbit could be used to implement an actual feature. Two examples that I have seen here are the e

[jira] Assigned: (JCR-533) refresh(false) don't remove falied lock from transiente session

[ http://issues.apache.org/jira/browse/JCR-533?page=all ] Stefan Guggisberg reassigned JCR-533: - Assignee: Stefan Guggisberg > refresh(false) don't remove falied lock from transiente session > -

Re: JSR170 for Source code Version control system

All , Incase if iam doing some patches for this , do i need to get some approval from someone .., please guide me with the procedure :-) On 8/7/06, Dave Bobby <[EMAIL PROTECTED]> wrote: Hi, Here is a suggestion. Jackrabbit is great tool to hold repositories. Node types are a great way to ex

Re: Re: using jackrabbit to store email with meta-data

On 8/7/06, Lars Heuer <[EMAIL PROTECTED]> wrote: Hi Robert, [...] >> Additionally I am interested in a good XML format for msgs. [...] > i suspect that the hardest part of the problem will be defining > exactly that good means in this context. any initial thoughts? We've collected some resourc

[jira] Updated: (JCR-442) Implement a backup tool

[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-060808-backup.txt - A few classes has been cleaned up and are ready for production (Until BackupManager not included) - There is still the NodeVers