You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (JIRA)" <ji...@apache.org> on 2007/10/04 09:41:50 UTC

[jira] Commented: (JCR-1159) SPI: improve description of locking methods on RepositoryService

    [ 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.