You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2007/10/03 18:44:50 UTC
[jira] Created: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
SPI: improve description of locking methods on RepositoryService
----------------------------------------------------------------
Key: JCR-1159
URL: https://issues.apache.org/jira/browse/JCR-1159
Project: Jackrabbit
Issue Type: Improvement
Components: SPI
Reporter: angela
Priority: Minor
in detail:
1) getLockInfo
- intended behavior if no lock is present?
- intended behavior if locking is not supported?
2) lock
- currently InvalidItemStateException is listed. i don't think this make too much sense.
3) refreshLock
- intended behavior if locking is not supported?
4) unlock
- currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532352 ]
Julian Reschke commented on JCR-1159:
-------------------------------------
Thanks for the proposal.
Typo:
"* @return returns the <code>LockInfo</code> associated with the new lock..."
s/returns//
In general, I'd prefer a design where (on the SPI level) we do not throw an exception for things that aren't exceptions in the program flow. In this case, I'd vote for letting getLockInfo return null if the node is not locked.
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Priority: Minor
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532385 ]
angela commented on JCR-1159:
-----------------------------
> I guess it would affect more stuff in the repository service...
i quickly stepped through the interfaces i couldn't find an additional case where it felt natural to me.
and the various Info interfaces already allow for null return values in those cases.
do you know of something else?
angela
btw: i think get-whatever-Factory methods on the RepositoryService should throw if they cannot return the required factory, since that would really reveal a fundamental problem... but they can't at the moment.
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Priority: Minor
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-1159:
-------------------------------
Fix Version/s: 1.4
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Assignee: angela
> Priority: Minor
> Fix For: 1.4
>
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532376 ]
Julian Reschke commented on JCR-1159:
-------------------------------------
In particular, as - in contrast to JCR - we do not have isLocked() etc.
So do we want to make this a general rule for SPI? I guess it would affect more stuff in the repository service...
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Priority: Minor
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-1159:
------------------------
Attachment: JCR-1159.patch
proposed solution for the listed questions/comments.
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Priority: Minor
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela reassigned JCR-1159:
---------------------------
Assignee: angela
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Assignee: angela
> Priority: Minor
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532375 ]
angela commented on JCR-1159:
-----------------------------
up to know we avoided 'null' return values in the RepositoryService interface (also in analogy to the JCR interfaces). on the other hand you are right, that asking for the LockInfo on a node should basically not throw an exception if no lock is present.
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Priority: Minor
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1159) SPI: improve description of locking
methods on RepositoryService
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved JCR-1159.
-------------------------
Resolution: Fixed
applied patch with modifications suggested by julian (getLockInfo returns null if no lock applies).
> SPI: improve description of locking methods on RepositoryService
> ----------------------------------------------------------------
>
> Key: JCR-1159
> URL: https://issues.apache.org/jira/browse/JCR-1159
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: angela
> Assignee: angela
> Priority: Minor
> Attachments: JCR-1159.patch
>
>
> in detail:
> 1) getLockInfo
> - intended behavior if no lock is present?
> - intended behavior if locking is not supported?
> 2) lock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
> 3) refreshLock
> - intended behavior if locking is not supported?
> 4) unlock
> - currently InvalidItemStateException is listed. i don't think this make too much sense.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.