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

2007-10-04 Thread Julian Reschke (JIRA)

[ 
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] Reopened: (JCR-1153) remove support for event bundle IDs

2007-10-04 Thread Julian Reschke (JIRA)

 [ 
https://issues.apache.org/jira/browse/JCR-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke reopened JCR-1153:
-


We need also to remove getBundleId.getBundleId().


 remove support for event bundle IDs
 ---

 Key: JCR-1153
 URL: https://issues.apache.org/jira/browse/JCR-1153
 Project: Jackrabbit
  Issue Type: Task
  Components: SPI
Reporter: Julian Reschke
Assignee: Julian Reschke
Priority: Minor

 Event bundle IDs currently are not used. We can re-add them later in case we 
 need them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [VOTE] Release Apache Jackrabbit 1.3.3

2007-10-04 Thread Julian Reschke

+1

Builds and passes tests with Java 1.5.0 on Win XP.

BR, Julian


Re: [VOTE] Release Apache Jackrabbit 1.3.3

2007-10-04 Thread Felix Meschberger
+1

Check signatures, checksums and license headers in the source distro.
All is ok now. Thanks.

Regards
Felix

Am Donnerstag, den 04.10.2007, 11:34 +0300 schrieb Jukka Zitting:
 Hi,
 
 After changing the incorrect license header in the 1.3.2 release
 candidate, I have now posted a candidate for the Apache Jackrabbit
 1.3.3 release at
 
   http://people.apache.org/~jukka/jackrabbit/1.3.3/
 
 See the included RELEASE-NOTES-1.3.3.txt file for details on release
 contents and latest changes. The release was made from the 1.3 branch
 after merging in all the changes listed in the release notes. The only
 changes after the 1.3.2 release candidate are one changed license
 header and the updated version number.
 
 The release candidate consists of the traditional source and binary
 packages as well as a staged Maven repository that contains the 1.3.3
 release artifacts.
 
 Please vote on releasing these packages as Apache Jackrabbit 1.3.3.
 The vote  passes if at least three +1 votes are cast.
 
[ ] +1 Release the packages as Apache Jackrabbit 1.3.3
[ ] -1 Do not release the packages because...
 
 Here's my +1, compiled and tested on Java 1.4.2 and 1.5.0 on Linux and
 Java 1.6.0 on Windows XP.
 
 BR,
 
 Jukka Zitting



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

2007-10-04 Thread angela (JIRA)

[ 
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

2007-10-04 Thread Julian Reschke (JIRA)

[ 
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] Resolved: (JCR-1160) JCR2SPI: test regression for WorkspaceMoveReferenceableTest.testMoveNodesReferenceableNodesNewUUID

2007-10-04 Thread angela (JIRA)

 [ 
https://issues.apache.org/jira/browse/JCR-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved JCR-1160.
-

Resolution: Fixed

 JCR2SPI: test regression for 
 WorkspaceMoveReferenceableTest.testMoveNodesReferenceableNodesNewUUID
 --

 Key: JCR-1160
 URL: https://issues.apache.org/jira/browse/JCR-1160
 Project: Jackrabbit
  Issue Type: Bug
  Components: SPI
Reporter: Julian Reschke
Assignee: angela

 The latest changes (up to 581637) seems to have broken TCK tests:
 ---
 Test set: org.apache.jackrabbit.test.TestAll
 ---
 Tests run: 1037, Failures: 6, Errors: 2, Skipped: 0, Time elapsed: 102.644 
 sec  FAILURE!
 testMoveNodesReferenceableNodesNewUUID(org.apache.jackrabbit.test.api.WorkspaceMoveReferenceableTest)
   Time elapsed: 0.03 sec   ERROR!
 javax.jcr.InvalidItemStateException: Item '[EMAIL PROTECTED]' doesn't exist 
 anymore
 at org.apache.jackrabbit.jcr2spi.ItemImpl.checkStatus(ItemImpl.java:428)
 at org.apache.jackrabbit.jcr2spi.NodeImpl.getName(NodeImpl.java:120)
 at 
 org.apache.jackrabbit.test.api.WorkspaceMoveReferenceableTest.testMoveNodesReferenceableNodesNewUUID(WorkspaceMoveReferenceableTest.java:57)
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.