[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 codeLockInfo/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
[ 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] 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_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.
