[jira] [Resolved] (OAK-273) ValueFormatException expected when overwriting single-valued property with multi-value and vice versa

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-273.


Resolution: Fixed

> ValueFormatException expected when overwriting single-valued property with 
> multi-value and vice versa
> -
>
> Key: OAK-273
> URL: https://issues.apache.org/jira/browse/OAK-273
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-273.diff
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-273) ValueFormatException expected when overwriting single-valued property with multi-value and vice versa

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439648#comment-13439648
 ] 

Julian Reschke commented on OAK-273:


Indeed. However, I don't see an easy way to consolidate both code flows 
(NodeImpl->NodeDelegate while PropertyImpl->Tree), so for now I'll commit the 
change as is.

> ValueFormatException expected when overwriting single-valued property with 
> multi-value and vice versa
> -
>
> Key: OAK-273
> URL: https://issues.apache.org/jira/browse/OAK-273
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-273.diff
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-273) ValueFormatException expected when overwriting single-valued property with multi-value and vice versa

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-273:
---

Attachment: OAK-273.diff

proposed patch

> ValueFormatException expected when overwriting single-valued property with 
> multi-value and vice versa
> -
>
> Key: OAK-273
> URL: https://issues.apache.org/jira/browse/OAK-273
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-273.diff
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-273) ValueFormatException expected when overwriting single-valued property with multi-value and vice versa

[Julian Reschke (JIRA)]

Julian Reschke created OAK-273:
--

 Summary: ValueFormatException expected when overwriting 
single-valued property with multi-value and vice versa
 Key: OAK-273
 URL: https://issues.apache.org/jira/browse/OAK-273
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: Julian Reschke
Priority: Minor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439486#comment-13439486
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1906, Errors: 19, Failures: 115

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439397#comment-13439397
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1906, Errors: 26, Failures: 114

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-271) make identifiers for non-referenceable nodes more stable

[Julian Reschke (JIRA)]

Julian Reschke created OAK-271:
--

 Summary: make identifiers for non-referenceable nodes more stable
 Key: OAK-271
 URL: https://issues.apache.org/jira/browse/OAK-271
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: Julian Reschke


Right now these identifiers are just the paths, and thus aren't stable in case 
of move/rename operations.

Jackrabbit uses the UUID of the closest referenceable ancestor plus a relative 
path. To compute this, we would however need to bypass access control checks.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439342#comment-13439342
 ] 

Julian Reschke commented on OAK-101:


The point being that the identifier handling as implemented is per spec (as far 
as I can tell), it's just not very useful for non-referenceable nodes.

If we believe this is insufficient (in which case I'd like to understand why) 
we should indeed leave this issue open. Otherwise, we should close it and open 
a new ticket once we decide we need stronger stability for these identifiers.

> implement identifier handling (byUUID, byIdentifier, etc)
> -
>
> Key: OAK-101
> URL: https://issues.apache.org/jira/browse/OAK-101
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
> Fix For: 0.5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439318#comment-13439318
 ] 

Julian Reschke commented on OAK-101:


Angela:

- not sure what you mean by "issue with property access"

- why discused the identifiers for non-referenceable nodes in Hamburg; if you 
feel the outcome is not good enough, I would recommend to open a separate issue 
for that

> implement identifier handling (byUUID, byIdentifier, etc)
> -
>
> Key: OAK-101
> URL: https://issues.apache.org/jira/browse/OAK-101
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
> Fix For: 0.5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-61) Implement JCR path handling

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-61.
---

Resolution: Fixed

I believe all functionality is there now; thus anything that's not working 
right now should be treated as separate bug.

> Implement JCR path handling
> ---
>
> Key: OAK-61
> URL: https://issues.apache.org/jira/browse/OAK-61
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: jcr
>Reporter: Michael Dürig
>
> This includes:
> - handling paths with full qualified names
> - identifier paths
> - handling remapped name space prefixes
> - validation
> - ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

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

Julian Reschke reopened OAK-66:
---


sorry, closed wrong issue

> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-66.
---

Resolution: Fixed

I believe all functionality is there now; thus anything that's not working 
right now should be treated as separate bug.

> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438534#comment-13438534
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1906, Errors: 27, Failures: 121

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-260) Avoid the "Turkish Locale Problem"

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438038#comment-13438038
 ] 

Julian Reschke commented on OAK-260:


For the record, the contract for equalsIgnoreCase:

  
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/String.html#equalsIgnoreCase%28java.lang.String%29

This may do the right thing for the Turkish locale, but I'm not totally 
convinced it couldn't fail with other fancy locales. It's probably better to 
always specify the locale.

> Avoid the "Turkish Locale Problem"
> --
>
> Key: OAK-260
> URL: https://issues.apache.org/jira/browse/OAK-260
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Thomas Mueller
>
> We currently use String.toUpperCase() and String.toLowerCase() and in some 
> cases where it is not appropriate. When running using the Turkish profile, 
> this will not work as expected. See also 
> http://mattryall.net/blog/2009/02/the-infamous-turkish-locale-bug
> Problematic are String.toUpperCase(), String.toLowerCase(). 
> String.equalsIgnoreCase(..) isn't a problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-23) Deal with non-standard JCR path passed to the API calls

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-23.
---

Resolution: Fixed

r1374976

> Deal with non-standard JCR path passed to the API calls
> ---
>
> Key: OAK-23
> URL: https://issues.apache.org/jira/browse/OAK-23
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
> Attachments: OAK-23.patch
>
>
> this issue corresponds to OAK-21 for path.
> in addition to dealing with expanded names, paths can also be 'identifier' 
> paths.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-11) Document and tighten contract of Microkernel API

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437774#comment-13437774
 ] 

Julian Reschke commented on OAK-11:
---

I would recommend that we define this as an alternate syntax to the patch 
semantics defined in draft-ietf-appsawg-json-patch, thus 
http://trac.tools.ietf.org/html/draft-ietf-appsawg-json-patch-02#section-4.1 
would define this (and the answer would be that this is an error).

> Document and tighten contract of Microkernel API
> 
>
> Key: OAK-11
> URL: https://issues.apache.org/jira/browse/OAK-11
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
>  Labels: documentation
>
> We should do a review of the Microkernel API with the goal to clarify, 
> disambiguate and document its contract.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-23) Deal with non-standard JCR path passed to the API calls

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-23:
--

Attachment: (was: OAK-23.patch)

> Deal with non-standard JCR path passed to the API calls
> ---
>
> Key: OAK-23
> URL: https://issues.apache.org/jira/browse/OAK-23
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
> Attachments: OAK-23.patch
>
>
> this issue corresponds to OAK-21 for path.
> in addition to dealing with expanded names, paths can also be 'identifier' 
> paths.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-23) Deal with non-standard JCR path passed to the API calls

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-23:
--

Attachment: OAK-23.patch

Proposed patch; there's one TODO left wrt OAK-23 we need to check (identifier 
path in path-typed property value)

> Deal with non-standard JCR path passed to the API calls
> ---
>
> Key: OAK-23
> URL: https://issues.apache.org/jira/browse/OAK-23
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
> Attachments: OAK-23.patch
>
>
> this issue corresponds to OAK-21 for path.
> in addition to dealing with expanded names, paths can also be 'identifier' 
> paths.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-23) Deal with non-standard JCR path passed to the API calls

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-23:
--

Attachment: OAK-23.patch

proposed patch; work in progress

> Deal with non-standard JCR path passed to the API calls
> ---
>
> Key: OAK-23
> URL: https://issues.apache.org/jira/browse/OAK-23
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
> Attachments: OAK-23.patch
>
>
> this issue corresponds to OAK-21 for path.
> in addition to dealing with expanded names, paths can also be 'identifier' 
> paths.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-23) Deal with non-standard JCR path passed to the API calls

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436799#comment-13436799
 ] 

Julian Reschke commented on OAK-23:
---

Moving it into the mapper is attractive because we then do not need to touch 
anything else (hopefully). It might be unattractive because we make something 
that was supposed to be simple a bit more complex.

FWIW, the check for identifier paths is for starts-with-[ and ends-with-], 
right?

> Deal with non-standard JCR path passed to the API calls
> ---
>
> Key: OAK-23
> URL: https://issues.apache.org/jira/browse/OAK-23
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
>
> this issue corresponds to OAK-21 for path.
> in addition to dealing with expanded names, paths can also be 'identifier' 
> paths.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436787#comment-13436787
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1906, Errors: 27, Failures: 118

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-23) Deal with non-standard JCR path passed to the API calls

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436776#comment-13436776
 ] 

Julian Reschke commented on OAK-23:
---

The notes in the source with respect to this ticket imply that identifier paths 
should be handled in the path mapper. However, that would imply that the path 
mapper can do identifier resolution -- is this really a good idea?

> Deal with non-standard JCR path passed to the API calls
> ---
>
> Key: OAK-23
> URL: https://issues.apache.org/jira/browse/OAK-23
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
>
> this issue corresponds to OAK-21 for path.
> in addition to dealing with expanded names, paths can also be 'identifier' 
> paths.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-21) Respect expanded JCR names

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436647#comment-13436647
 ] 

Julian Reschke commented on OAK-21:
---

I believe this can be closed in the meantime.

> Respect expanded JCR names
> --
>
> Key: OAK-21
> URL: https://issues.apache.org/jira/browse/OAK-21
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
>
> currently the oak-jcr code does not respect the expanded JCR names.
> since all the name constants in the JCR API are in the expanded form we
> need to properly convert all JCR name parameters passed to the JCR API calls.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-21) Respect expanded JCR names

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-21.
---

Resolution: Fixed

> Respect expanded JCR names
> --
>
> Key: OAK-21
> URL: https://issues.apache.org/jira/browse/OAK-21
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
>
> currently the oak-jcr code does not respect the expanded JCR names.
> since all the name constants in the JCR API are in the expanded form we
> need to properly convert all JCR name parameters passed to the JCR API calls.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13435982#comment-13435982
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1906, Errors: 26, Failures: 121

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-178) Query: index definition documentation and tooling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421427#comment-13421427
 ] 

Julian Reschke commented on OAK-178:


bq. Should it be /jcr:system/oak:indexes instead? 

Yes.

bq. If yes, is the patch above the correct way (to your knowledge) to register 
the "oak" namespace?

I believe so; we may want to lose the trailing "1.0", though...



> Query: index definition documentation and tooling
> -
>
> Key: OAK-178
> URL: https://issues.apache.org/jira/browse/OAK-178
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>
> Unlike Jackrabbit 2.x, indexes in the Oak query engine are user defined, that 
> means data is only indexed if there is a matching index. Those indexes are 
> then automatically used for the appropriate queries. The current plan is to 
> define indexes as nodes within a repository. An index is created if an index 
> metadata node is created, and the index is removed if the index metadata node 
> is removed. The index content is automatically updated if the content changes 
> (either synchronously or asynchronously).
> The location and structure of the index metadata needs to be defined and 
> documented.
> Also, to simplify defining and managing indexes, it may make sense to write a 
> utility (helper class) for managing indexes. Internally, this utility uses 
> the regular JCR API and accesses the documented index metadata nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421377#comment-13421377
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1906, Errors: 26, Failures: 119

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-204) short cutting the name mapping breaks path validation in value factory

[Julian Reschke (JIRA)]

Julian Reschke created OAK-204:
--

 Summary: short cutting the name mapping breaks path validation in 
value factory
 Key: OAK-204
 URL: https://issues.apache.org/jira/browse/OAK-204
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: Julian Reschke
Priority: Minor


With the optimizations for path mapping in place, the test case

  org.apache.jackrabbit.test.api.ValueFactoryTest#testValueFormatException

fails because it expects an early ValueFormatException due to an invalid path.

We either need to consider adding some basic validity checking, or have to 
rewire the ValueFactory name mapping code to do additional validity checks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-187) ConcurrentModificationException during gc run

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420730#comment-13420730
 ] 

Julian Reschke commented on OAK-187:


Saw that today as well.

> ConcurrentModificationException during gc run
> -
>
> Key: OAK-187
> URL: https://issues.apache.org/jira/browse/OAK-187
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mk
>Reporter: Michael Dürig
>
> I sporadically encounter a {{ConcurrentModificationException}} when building 
> with {{-PintegrationTesting}}. This happens while the {{JcrTckTest}} suite 
> runs and is only printed to the console. No tests fail.
> {code}
> Running org.apache.jackrabbit.oak.jcr.JcrTckIT
> java.util.ConcurrentModificationException
>   at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131)
>   at 
> org.apache.jackrabbit.mk.store.DefaultRevisionStore.markBranches(DefaultRevisionStore.java:562)
>   at 
> org.apache.jackrabbit.mk.store.DefaultRevisionStore.gc(DefaultRevisionStore.java:498)
>   at 
> org.apache.jackrabbit.mk.store.DefaultRevisionStore$2.run(DefaultRevisionStore.java:160)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>   at 
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:680)
> Tests run: 1906, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.443 sec
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-201) NamespaceRegistry is very slow

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420601#comment-13420601
 ] 

Julian Reschke commented on OAK-201:


OK, that's a case where we get the node type name from the caller, and where we 
need to support both remapped prefixes and expanded names.

I'll get to the missing optimization in the name mapper for this case this 
afternoon.

> NamespaceRegistry is very slow
> --
>
> Key: OAK-201
> URL: https://issues.apache.org/jira/browse/OAK-201
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Thomas Mueller
>
> The NamespaceRegistryImpl.getURI and getPrefix are called a lot, for example 
> by NamePathMapperImpl.getOakName. 
> The method doesn't do any caching, which is a problem because it has to read 
> it each time from the repository. Even if it would do caching, it wouldn't 
> help because it the method WorkspaceImpl.getNamespaceRegistry creates a new 
> NamespaceRegistryImpl each time it is called. To allow caching of known 
> mappings, the instance needs to be cached as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-201) NamespaceRegistry is very slow

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420583#comment-13420583
 ] 

Julian Reschke commented on OAK-201:


That would work; but wouldn't it be simpler if we just used constants for the 
node type names using the known OAK prefixes? (and not use expanded names at 
all here)

> NamespaceRegistry is very slow
> --
>
> Key: OAK-201
> URL: https://issues.apache.org/jira/browse/OAK-201
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Thomas Mueller
>
> The NamespaceRegistryImpl.getURI and getPrefix are called a lot, for example 
> by NamePathMapperImpl.getOakName. 
> The method doesn't do any caching, which is a problem because it has to read 
> it each time from the repository. Even if it would do caching, it wouldn't 
> help because it the method WorkspaceImpl.getNamespaceRegistry creates a new 
> NamespaceRegistryImpl each time it is called. To allow caching of known 
> mappings, the instance needs to be cached as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-201) NamespaceRegistry is very slow

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420553#comment-13420553
 ] 

Julian Reschke commented on OAK-201:


bq.  The name mapper could avoid all namespace lookups as long as no 
session-local namespace remappings are in effect.

I can look at that optimization, but the calls might also be caused by 
JCR-level calls that use expanded names.

Thomas, do you have a few call stacks?

> NamespaceRegistry is very slow
> --
>
> Key: OAK-201
> URL: https://issues.apache.org/jira/browse/OAK-201
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Thomas Mueller
>
> The NamespaceRegistryImpl.getURI and getPrefix are called a lot, for example 
> by NamePathMapperImpl.getOakName. 
> The method doesn't do any caching, which is a problem because it has to read 
> it each time from the repository. Even if it would do caching, it wouldn't 
> help because it the method WorkspaceImpl.getNamespaceRegistry creates a new 
> NamespaceRegistryImpl each time it is called. To allow caching of known 
> mappings, the instance needs to be cached as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412921#comment-13412921
 ] 

Julian Reschke commented on OAK-66:
---

Today I tried two approaches, which in the end turned out to be a BIG mess:

1) Copy over the relevant code from jcr2spi and spicommons; replacing all 
instances of Name and Path by String. Trouble is; these are really many 
classes, and it's not clear that hacking them this way will be useful.

2) Try to refactor SPI to make everything that uses Name and Path to use 
Generics. This looked promising first, but again got messy really quick.

Tomorrow I'll try something else to make progress: in OAK-JCR; simply implement 
Name and Path as wrappers around Strings containing Oak names and paths. This 
will add additional objects, but might be the best way to get something up and 
running quickly without duplicating tons of code.

> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-178) Query: index definition documentation and tooling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411583#comment-13411583
 ] 

Julian Reschke commented on OAK-178:


Or:

  /jcr:system/oak:indexes

and define an Oak namespace (we'll need that for new node types etc anyway).

> Query: index definition documentation and tooling
> -
>
> Key: OAK-178
> URL: https://issues.apache.org/jira/browse/OAK-178
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>
> Unlike Jackrabbit 2.x, indexes in the Oak query engine are user defined, that 
> means data is only indexed if there is a matching index. Those indexes are 
> then automatically used for the appropriate queries. The current plan is to 
> define indexes as nodes within a repository. An index is created if an index 
> metadata node is created, and the index is removed if the index metadata node 
> is removed. The index content is automatically updated if the content changes 
> (either synchronously or asynchronously).
> The location and structure of the index metadata needs to be defined and 
> documented.
> Also, to simplify defining and managing indexes, it may make sense to write a 
> utility (helper class) for managing indexes. Internally, this utility uses 
> the regular JCR API and accesses the documented index metadata nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-74) avoid use of "internal" namespace

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410341#comment-13410341
 ] 

Julian Reschke commented on OAK-74:
---

One way to do this would be to remap this namespace name (*) to a hardwired 
proper URI.

(*) or all invalid namespace names to a set of hardwired proper URIs.

Example:

internal -> http://jackrabbit.apache.org/ns/remapped/internal

> avoid use of "internal" namespace
> -
>
> Key: OAK-74
> URL: https://issues.apache.org/jira/browse/OAK-74
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Priority: Minor
>
> We should try to avoid using the "internal" namespace in Oak (reminder: the 
> string "internal" is not a valid URI)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409638#comment-13409638
 ] 

Julian Reschke commented on OAK-66:
---

Documenting a path I tried and shouldn't have taken: wanted to make the 
NodeTypeManagerDelegate attached to the repository (so that it's bootstrap only 
happens once), changed internal name format to clark notation (because at that 
time I don't have access to the repo yet), but failed (because of the CND file 
using namespaces in the "internal" namespace which do not work in clark 
notation, when done properly).

> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-169) Support orderable nodes

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407913#comment-13407913
 ] 

Julian Reschke edited comment on OAK-169 at 7/6/12 11:52 AM:
-

I believe the idea is to have only a partial ordering (you can rely on the 
order of only those entries that have been re-ordered).

Not sure how well this is going to work in practice, because that wouldn't 
satisfy the requirements in 
http://www.day.com/specs/jcr/2.0/23_Orderable_Child_Nodes.html (namely that the 
ordering is consistent for *all* child nodes, and that new nodes are added to 
the end).

  was (Author: reschke):
I believe the idea is to have only a partial ordering (you can rely on the 
order of only those entries that have been re-ordered).

Not sure how well this is going to work in practice...
  
> Support orderable nodes
> ---
>
> Key: OAK-169
> URL: https://issues.apache.org/jira/browse/OAK-169
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: jcr
>Reporter: Jukka Zitting
>
> There are JCR clients that depend on the ability to explicitly specify the 
> order of child nodes. That functionality is not included in the MicroKernel 
> tree model, so we need to implement it either in oak-core or oak-jcr using 
> something like an extra (hidden) {{oak:childOrder}} property that records the 
> specified ordering of child nodes. A multi-valued string property is probably 
> good enough for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-169) Support orderable nodes

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407913#comment-13407913
 ] 

Julian Reschke commented on OAK-169:


I believe the idea is to have only a partial ordering (you can rely on the 
order of only those entries that have been re-ordered).

Not sure how well this is going to work in practice...

> Support orderable nodes
> ---
>
> Key: OAK-169
> URL: https://issues.apache.org/jira/browse/OAK-169
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: jcr
>Reporter: Jukka Zitting
>
> There are JCR clients that depend on the ability to explicitly specify the 
> order of child nodes. That functionality is not included in the MicroKernel 
> tree model, so we need to implement it either in oak-core or oak-jcr using 
> something like an extra (hidden) {{oak:childOrder}} property that records the 
> specified ordering of child nodes. A multi-valued string property is probably 
> good enough for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-163) Move the JCR TCK back to the integrationTesting profile

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406419#comment-13406419
 ] 

Julian Reschke commented on OAK-163:


bq. That's what we have the CI build for.

Downsides: Hasn't been always reliable. Problem is found only after checkin. 
Developer might not see it in time (end-of-day, vacation) or not paying 
attention. Etc.

> Move the JCR TCK back to the integrationTesting profile
> ---
>
> Key: OAK-163
> URL: https://issues.apache.org/jira/browse/OAK-163
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: tck
> Attachments: 
> 0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch
>
>
> In revision 1325811 the JCR TCK tests were moved from the integrationTesting 
> profile to a normal build. However, since then the execution time of the TCK 
> has grown to 3+ minutes, which is more than the rest of the Oak build 
> combined. To keep the build time down to at most a couple of minutes, I'd 
> like to move the TCK run back to the integrationTesting profile where it will 
> get executed only when explicitly requested (typically manually before a 
> commit or after one in a CI build).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-163) Move the JCR TCK back to the integrationTesting profile

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406398#comment-13406398
 ] 

Julian Reschke commented on OAK-163:


There's a risk that people *won't* run the TCK before checking in, causing loss 
of cycles for somebody else later on.

Also, running with integrationTesting is so slow for jackrabbit that most 
people won't wait for it to finish before checking in. So what may be right for 
OAK definitively is not right for Jackrabbit.

> Move the JCR TCK back to the integrationTesting profile
> ---
>
> Key: OAK-163
> URL: https://issues.apache.org/jira/browse/OAK-163
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: tck
> Attachments: 
> 0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch
>
>
> In revision 1325811 the JCR TCK tests were moved from the integrationTesting 
> profile to a normal build. However, since then the execution time of the TCK 
> has grown to 3+ minutes, which is more than the rest of the Oak build 
> combined. To keep the build time down to at most a couple of minutes, I'd 
> like to move the TCK run back to the integrationTesting profile where it will 
> get executed only when explicitly requested (typically manually before a 
> commit or after one in a CI build).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-163) Move the JCR TCK back to the integrationTesting profile

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405916#comment-13405916
 ] 

Julian Reschke commented on OAK-163:


Not convinced; we run them as part of the default jackrabbit build as well.

> Move the JCR TCK back to the integrationTesting profile
> ---
>
> Key: OAK-163
> URL: https://issues.apache.org/jira/browse/OAK-163
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: tck
>
> In revision 1325811 the JCR TCK tests were moved from the integrationTesting 
> profile to a normal build. However, since then the execution time of the TCK 
> has grown to 3+ minutes, which is more than the rest of the Oak build 
> combined. To keep the build time down to at most a couple of minutes, I'd 
> like to move the TCK run back to the integrationTesting profile where it will 
> get executed only when explicitly requested (typically manually before a 
> commit or after one in a CI build).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-158) Specify fixed memory settings for unit and integration tests

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-158:
---

Attachment: OAK-158.diff

The tests work for me with 128m, see attached diff (my Java default was way 
higher). I would recommend that we set the limit to 128m for now, so that we 
find out ASAP once the system starts to consume more.

> Specify fixed memory settings for unit and integration tests
> 
>
> Key: OAK-158
> URL: https://issues.apache.org/jira/browse/OAK-158
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: parent
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Minor
> Attachments: OAK-158.diff
>
>
> To reduce the chance of different build results on different platforms, it 
> would be good to specify fixed memory limits for our unit and integration 
> tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-155) Query: limited support for the deprecated JCR 1.0 query language Query.SQL

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402980#comment-13402980
 ] 

Julian Reschke commented on OAK-155:


Sounds right to me. As far as I recall, if we can map XPath as specified in JCR 
1.0, then we should also be able to map SQL (as per JCR 1.0).

Reminder: given a different query parser we may end up with differences in how 
invalid queries are handled; Jackrabbit IMHO is very forgiving when seeing 
things it doesn't understand.

> Query: limited support for the deprecated JCR 1.0 query language Query.SQL
> --
>
> Key: OAK-155
> URL: https://issues.apache.org/jira/browse/OAK-155
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Thomas Mueller
>
> Existing applications (as well as the TCK) use the JCR 1.0 query language
> "sql". As far as I know, there are only few differences between JCR 1.0 SQL 
> and JCR 2.0 SQL-2. To make old applications work with Oak, I suggest we 
> provide support JCR 1.0 SQL as well. An additional advantage is that more of 
> the existing TCK tests can be run.
> I currently don't know if the full JCR 1.0 SQL syntax can be supported 
> (similar to XPath); if we find supporting certain features is too complicated 
> we will document those limitations instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402955#comment-13402955
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 25, Failures: 108 (with Observation 
temporarily disabled)

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-150) Basic JCR LockManager support

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400466#comment-13400466
 ] 

Julian Reschke commented on OAK-150:


As far as I recall, MS Office (when using WebDAV) expects:

- that the LOCK operation succeeds and returns a lock token
- that timeout information is preserved and actually works (if the lock token 
is lost)
- that the lock token can be discovered (WebDAV DAV:lockdiscovery)

Support for user-supplied owner information probably might not be necessary 
anymore.

The MacOS webdav stack IMHO also tries to LOCK and will otherwise fail (?). 
Dunno what features it needs specifically.



> Basic JCR LockManager support
> -
>
> Key: OAK-150
> URL: https://issues.apache.org/jira/browse/OAK-150
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>  Labels: locking
>
> Even though we currently don't (and perhaps never will) support full JCR 
> locking functionality in Oak, it would still be good to have a basic 
> LockManager implementation for clients that assume it's present and use it 
> simply to access lock tokens and to ask whether a particular node is locked 
> or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295511#comment-13295511
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 24, Failures: 107

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290286#comment-13290286
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 24, Failures: 110

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-131) Session.save() silently discards pending changes

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290263#comment-13290263
 ] 

Julian Reschke commented on OAK-131:


Jukka's proposal (see 
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201206.mbox/%3CCAOFYJNY4DgwpBPrxDp71t2vsMyOt3+jwmeq2=qwfpay+fre...@mail.gmail.com%3E):

"Perhaps we should replace such cases with conflict markers that
prevent the transient space from being resolved (for example with a
commit hook that prevents such markers from being present in commit).
Only if the session then explicitly removes or re-adds the modified
subtree, thus clearing the conflict marker, can the save succeed."

> Session.save() silently discards pending changes
> 
>
> Key: OAK-131
> URL: https://issues.apache.org/jira/browse/OAK-131
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>
> SessionTest.testSaveInvalidStateException fails in OAK because save() 
> implicitly calls refresh(true) (which is good), but refresh(true) discards 
> pending changes (because the node being modified is gone in persistent 
> storage).
> See also mail thread starting here: 
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201206.mbox/browser

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-132) issues related to Node.save() as opposed to Session.save()

[Julian Reschke (JIRA)]

Julian Reschke created OAK-132:
--

 Summary: issues related to Node.save() as opposed to Session.save()
 Key: OAK-132
 URL: https://issues.apache.org/jira/browse/OAK-132
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: jcr
Reporter: Julian Reschke
Priority: Minor


(This issue is opened for tracking purposes.)

JSR-283 deprecates Node.save(). OAK-JCR implements it by delegating to the 
session.

The TCK has a few test cases that rely on the JSR-170/283 semantics.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-131) Session.save() silently discards pending changes

[Julian Reschke (JIRA)]

Julian Reschke created OAK-131:
--

 Summary: Session.save() silently discards pending changes
 Key: OAK-131
 URL: https://issues.apache.org/jira/browse/OAK-131
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: Julian Reschke


SessionTest.testSaveInvalidStateException fails in OAK because save() 
implicitly calls refresh(true) (which is good), but refresh(true) discards 
pending changes (because the node being modified is gone in persistent storage).

See also mail thread starting here: 
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201206.mbox/browser


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-16) Proper ValueFactory implementation and Value handling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290168#comment-13290168
 ] 

Julian Reschke commented on OAK-16:
---

It is. :-)

> Proper ValueFactory implementation and Value handling
> -
>
> Key: OAK-16
> URL: https://issues.apache.org/jira/browse/OAK-16
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
>Assignee: angela
> Fix For: 0.3
>
>
> the GlobalContext contains the following code:
> put(ValueFactory.class, new SimpleValueFactory());
> that doesn't work as the ValueFactory needs to be bound to each session 
> instance
> in order to be able to deal with namespace mappings, paths, names etc
> michi, just told me that in addition the ValueConverted needs some focus as 
> well.
> and yesterday, i saw that Property#getType implementation in the 
> jackrabbit-mikrokernel
> was not correct... 
> just to mention a few issues

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-16) Proper ValueFactory implementation and Value handling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290153#comment-13290153
 ] 

Julian Reschke commented on OAK-16:
---

{quote}in addition there are still some value related tck test failing. some of 
those
may be caused by missing validation either on oak-jcr or on oak-core... i need 
to take
a closer look at this again.{quote}

Indeed; {{SetValueFormatExceptionTest}} has many failures because nobody checks 
the type when overwriting the value. The test case asks for an immediate 
failure, so I don't think it's sufficient to handle that in a commit hook; 
where should the check happen? oak-jcr or oak-core?

> Proper ValueFactory implementation and Value handling
> -
>
> Key: OAK-16
> URL: https://issues.apache.org/jira/browse/OAK-16
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
>Assignee: angela
> Fix For: 0.3
>
>
> the GlobalContext contains the following code:
> put(ValueFactory.class, new SimpleValueFactory());
> that doesn't work as the ValueFactory needs to be bound to each session 
> instance
> in order to be able to deal with namespace mappings, paths, names etc
> michi, just told me that in addition the ValueConverted needs some focus as 
> well.
> and yesterday, i saw that Property#getType implementation in the 
> jackrabbit-mikrokernel
> was not correct... 
> just to mention a few issues

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290116#comment-13290116
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 25, Failures: 111

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-61) Implement JCR path handling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290039#comment-13290039
 ] 

Julian Reschke edited comment on OAK-61 at 6/6/12 9:20 AM:
---

Updated status:

# The mapper now knows whether there are prefix remappings. The conversion code 
takes advantage of it (short cutting certain conversions), and we have a few 
tests for that. However, the session namespace remapper doesn't provide this 
information yet (it always says "I have remappings"), because we need to 
refactor the prefix handling in SessionImpl for that.
# Refactored the PathParser so that names and indices are handled atomically 
(needed for: see below)
# Added a variant of getOakPath that keeps the index information, but, contrary 
to what was discussed before, does normalization. This was needed so that code 
that check the last path segment (such as addNode()) can conveniently extract 
the last segment. The new method is currently only used for addNode(), copy() 
and move().

If we need a method that does prefix rewriting but no normalization we can add 
this later on.

  was (Author: reschke):
Updated status:

# The mapper now knows whether there are prefix remappings. The conversion code 
takes advantage of it (short cutting certain conversions), and we have a few 
tests for that. However, the session namespace remapper doesn't provide this 
information yet (it always says "I have remappings"), because we need to 
refactor the prefix handling in SessionImpl for that.
# Refactored the PathParser so that names and indices are handled atomically 
(needed for: see below)
# Added a variant of getOakPath that keeps the index information, but, contrary 
to what was discussed before, does normalization. This was needed so that code 
that check the last path segment (such as addNode()) can conveniently extract 
the last segment. The new method is currently only used for addNode(), copy() 
and move().
  
> Implement JCR path handling
> ---
>
> Key: OAK-61
> URL: https://issues.apache.org/jira/browse/OAK-61
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: jcr
>Reporter: Michael Dürig
>
> This includes:
> - handling paths with full qualified names
> - identifier paths
> - handling remapped name space prefixes
> - validation
> - ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-61) Implement JCR path handling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290039#comment-13290039
 ] 

Julian Reschke commented on OAK-61:
---

Updated status:

# The mapper now knows whether there are prefix remappings. The conversion code 
takes advantage of it (short cutting certain conversions), and we have a few 
tests for that. However, the session namespace remapper doesn't provide this 
information yet (it always says "I have remappings"), because we need to 
refactor the prefix handling in SessionImpl for that.
# Refactored the PathParser so that names and indices are handled atomically 
(needed for: see below)
# Added a variant of getOakPath that keeps the index information, but, contrary 
to what was discussed before, does normalization. This was needed so that code 
that check the last path segment (such as addNode()) can conveniently extract 
the last segment. The new method is currently only used for addNode(), copy() 
and move().

> Implement JCR path handling
> ---
>
> Key: OAK-61
> URL: https://issues.apache.org/jira/browse/OAK-61
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: jcr
>Reporter: Michael Dürig
>
> This includes:
> - handling paths with full qualified names
> - identifier paths
> - handling remapped name space prefixes
> - validation
> - ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289607#comment-13289607
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 27, Failures: 111

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288001#comment-13288001
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 27, Failures: 114

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286575#comment-13286575
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 28, Failures: 115

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-61) Implement JCR path handling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285696#comment-13285696
 ] 

Julian Reschke commented on OAK-61:
---

The current approach should be extended to:

# split the *mapping* operation from the *resolution* operation; *mapping* 
should not affect index handling ({{foo[1]}}), so that methods that need to 
check for valid names to be added (such as in {{addNode}}) can do so
# optimize the case where nothing needs to be rewritten (for instance, when the 
JCR path does not contain expanded names, and there is no session-local prefix 
remapping)

> Implement JCR path handling
> ---
>
> Key: OAK-61
> URL: https://issues.apache.org/jira/browse/OAK-61
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: jcr
>Reporter: Michael Dürig
>
> This includes:
> - handling paths with full qualified names
> - identifier paths
> - handling remapped name space prefixes
> - validation
> - ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285670#comment-13285670
 ] 

Julian Reschke commented on OAK-101:


We discussed the current handling at the Hamburg Oakathon; in theory it's 
desirable to have identifiers that are more stable. One way to achieve this 
would be to make them relative to the closest referenceable parent node. The 
downside is that the information needed for this computation may be 
access-restricted, and thus may not be available to any caller.

To deal with this we talked about two different approaches:

# Expose OAK nodes in a way that they can be traversed for name resolution even 
though they may not be readable
# Push down identifier computation and lookup to oak-core.

In the end we decided *not* to deal with this right now, as it's not clear that 
the stability of these identifiers really is a problem. We may have to revisit 
this if we get to support of multiple workspaces.

> implement identifier handling (byUUID, byIdentifier, etc)
> -
>
> Key: OAK-101
> URL: https://issues.apache.org/jira/browse/OAK-101
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285663#comment-13285663
 ] 

Julian Reschke edited comment on OAK-101 at 5/30/12 1:53 PM:
-

The current status of identifier handling is:

* the identifier of nodes that seem to be referenceable (weak node type 
check...) is the value of their {{jcr:uuid}} property

* otherwise the identifier is the OAK path

This means that identifiers of non-referenceable nodes currently are unstable 
(they change on rename/move) operations, and the {{IDENTIFIER_STABILITY}} 
repository descriptor should reflect that.

Lookup is done by inspecting the identifier value, and getting the node by OAK 
path (for identifiers that look like an absolute path), and using a OAK query 
for the {{jcr:uuid}} otherwise.



  was (Author: reschke):
The current status of identifier handling is:

* the identifier of nodes that seem to be referenceable (weak node type 
check...) is the value of their {{jcr:uuid}} property

* otherwise the identifier is the OAK path

Lookup is done by inspecting the identifier value, and getting the node by OAK 
path (for identifiers that look like an absolute path), and using a OAK query 
for the {{jcr:uuid}} otherwise.
  
> implement identifier handling (byUUID, byIdentifier, etc)
> -
>
> Key: OAK-101
> URL: https://issues.apache.org/jira/browse/OAK-101
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285663#comment-13285663
 ] 

Julian Reschke commented on OAK-101:


The current status of identifier handling is:

* the identifier of nodes that seem to be referenceable (weak node type 
check...) is the value of their {{jcr:uuid}} property

* otherwise the identifier is the OAK path

Lookup is done by inspecting the identifier value, and getting the node by OAK 
path (for identifiers that look like an absolute path), and using a OAK query 
for the {{jcr:uuid}} otherwise.

> implement identifier handling (byUUID, byIdentifier, etc)
> -
>
> Key: OAK-101
> URL: https://issues.apache.org/jira/browse/OAK-101
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned OAK-101:
--

Assignee: Julian Reschke

> implement identifier handling (byUUID, byIdentifier, etc)
> -
>
> Key: OAK-101
> URL: https://issues.apache.org/jira/browse/OAK-101
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282489#comment-13282489
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 30, Failures: 114


> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281662#comment-13281662
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 32, Failures: 115

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281101#comment-13281101
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 36, Failures: 115

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-108) Shortcut path conversions

[Julian Reschke (JIRA)]

Julian Reschke created OAK-108:
--

 Summary: Shortcut path conversions
 Key: OAK-108
 URL: https://issues.apache.org/jira/browse/OAK-108
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: jcr
Reporter: Julian Reschke


It would be nice if we could shortcut path conversions in order to minimize the 
cost of converting between OAK paths and JCR paths.

For instance, when going from OAK to JCR (assuming that the path is valid and 
normalized to begin with), we should be able to avoid prefix remapping 
completely if there are no session prefix remappings. To detect the latter, 
we'll however have to override or extend the namespace handling inside 
jcr-commons abstract-session.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278684#comment-13278684
 ] 

Julian Reschke commented on OAK-37:
---

For Eclipse, I recommend adding the FindBugs plugin. Update site: 
http://findbugs.cs.umd.edu/eclipse

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Attachments: nullability.patch, nullability.patch
>
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276834#comment-13276834
 ] 

Julian Reschke commented on OAK-37:
---

bq. PS. The Maven dependencies should have a provided entry in 
them. Otherwise they'll show up as transitive dependencies in downstream 
components. See for example the bndlib dependency for an example of another 
annotation library we're using.

Done; see attachment. Should I go ahead and commit this, and see how it works 
in practice once we add more annotations?

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Attachments: nullability.patch, nullability.patch
>
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-37:
--

Attachment: nullability.patch

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Attachments: nullability.patch, nullability.patch
>
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-37:
--

Attachment: nullability.patch

Minimal demonstration, showing how to embed the annotations.

Note:

- cross project checking with the FindBugs plugin in Eclipse indeed works

- FindBugs report:
Possible null pointer dereference in 
org.apache.jackrabbit.oak.jcr.security.user.UserManagerImpl.removeInternalProperty(Node,
 String) due to return value of called method  UserManagerImpl.java
/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/security/user  line 
352FindBugs Problem (Troubling)

I believe this is something we should do; running FindBugs from the actual 
Maven build would be the next step

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Attachments: nullability.patch
>
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-37:
--

Attachment: (was: nullability.patch)

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-37:
--

Attachment: nullability.patch

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276776#comment-13276776
 ] 

Julian Reschke commented on OAK-37:
---

Note that the nullability annotations in edu.umd.cs.findbugs.annotations are 
marked as deprecated; so maybe we really should use the "JSR305" variant.

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>Assignee: Julian Reschke
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276668#comment-13276668
 ] 

Julian Reschke commented on OAK-37:
---

bq. FindBugs annotations sound good to me as long as they don't introduce a 
mandatory runtime dependency on the code (which I don't think they do).

For intra-subproject checking they are only needed at compile time. However, 
I'm not sure how it will work when we use a JAR from another subproject. But 
let's start simple.

bq. IDE support (IntelliJ, Eclipse, etc.) is nice, but IMHO not essential. The 
important bit is that we're able to configure our Maven build to check such 
annotations and fail the build if the explicitly declared rules are broken.

That should be possible but maybe I'll need some hand-holding with that.

> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-23) Deal with non-standard JCR path passed to the API calls

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274681#comment-13274681
 ] 

Julian Reschke commented on OAK-23:
---

Applied the following WIP changes:

- SessionImpl.getItem(identifier) delegates to getNodeByIdentifier -- we may 
want to move this to AbstractSession instead

- move identifier handling from *Impl to *Delegate

- sepcial-case identifier paths in PropertyImpl/ValueImpl/ValueFactoryImpl - 
maybe this should happen in a special variant of the path mappers instead

(Reminder: for now a node's identifier is it's Oak path; we do not handle 
mix:referenceable at all)

> Deal with non-standard JCR path passed to the API calls
> ---
>
> Key: OAK-23
> URL: https://issues.apache.org/jira/browse/OAK-23
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: angela
>
> this issue corresponds to OAK-21 for path.
> in addition to dealing with expanded names, paths can also be 'identifier' 
> paths.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274675#comment-13274675
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 52, Failures: 179

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-101:
---

Component/s: jcr

> implement identifier handling (byUUID, byIdentifier, etc)
> -
>
> Key: OAK-101
> URL: https://issues.apache.org/jira/browse/OAK-101
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-101) implement identifier handling (byUUID, byIdentifier, etc)

[Julian Reschke (JIRA)]

Julian Reschke created OAK-101:
--

 Summary: implement identifier handling (byUUID, byIdentifier, etc)
 Key: OAK-101
 URL: https://issues.apache.org/jira/browse/OAK-101
 Project: Jackrabbit Oak
  Issue Type: Bug
Reporter: Julian Reschke




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273344#comment-13273344
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 57, Failures: 181

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-99) reading binary content fails for certain types of content

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-99.
---

Resolution: Fixed

This has been resolved with revision 1337132 
(http://svn.apache.org/viewvc?view=revision&revision=1337132)

> reading binary content fails for certain types of content
> -
>
> Key: OAK-99
> URL: https://issues.apache.org/jira/browse/OAK-99
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>
> With r1336746 I have added test content for export tests; and get the failure 
> below:
> org.apache.jackrabbit.mk.api.MicroKernelException: 
> org.apache.jackrabbit.mk.api.MicroKernelException: SGVsbG8gd8O2cmxkLg== 
>  at 
> org.apache.jackrabbit.mk.core.MicroKernelImpl.read(MicroKernelImpl.java:490)
>  at 
> org.apache.jackrabbit.mk.util.MicroKernelInputStream.read(MicroKernelInputStream.java:56)
>  at java.io.InputStream.read(Unknown Source)
>  at org.apache.jackrabbit.util.Base64.encode(Base64.java:156)
>  at org.apache.jackrabbit.value.ValueHelper.serialize(ValueHelper.java:681)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportValue(SystemViewExporter.java:129)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportProperty(SystemViewExporter.java:109)
>  at 
> org.apache.jackrabbit.commons.xml.Exporter.exportProperty(Exporter.java:361)
>  at 
> org.apache.jackrabbit.commons.xml.Exporter.exportProperties(Exporter.java:268)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:77)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:143)
>  at 
> org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:548)
>  at 
> org.apache.jackrabbit.commons.AbstractSession.exportSystemView(AbstractSession.java:257)
>  at 
> org.apache.jackrabbit.test.api.ExportSysViewTest.doTestWithHandler(ExportSysViewTest.java:126)
>  at 
> org.apache.jackrabbit.test.api.ExportSysViewTest.testExportSysView_handler_session_saveBinary_recurse(ExportSysViewTest.java:94)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>  at java.lang.reflect.Method.invoke(Unknown Source)
>  at junit.framework.TestCase.runTest(TestCase.java:168)
>  at junit.framework.TestCase.runBare(TestCase.java:134)
>  at junit.framework.TestResult$1.protect(TestResult.java:110)
>  at junit.framework.TestResult.runProtected(TestResult.java:128)
>  at junit.framework.TestResult.run(TestResult.java:113)
>  at junit.framework.TestCase.run(TestCase.java:124)
>  at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456)
>  at junit.framework.TestSuite.runTest(TestSuite.java:243)
>  at junit.framework.TestSuite.run(TestSuite.java:238)
>  at junit.framework.TestSuite.runTest(TestSuite.java:243)
>  at junit.framework.TestSuite.run(TestSuite.java:238)
>  at junit.framework.TestSuite.runTest(TestSuite.java:243)
>  at 
> org.apache.jackrabbit.test.ConcurrentTestSuite.access$1(ConcurrentTestSuite.java:1)
>  at 
> org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67)
>  at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
>  at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.jackrabbit.mk.api.MicroKernelException: 
> SGVsbG8gd8O2cmxkLg== 
>  at 
> org.apache.jackrabbit.mk.util.ExceptionFactory.convert(ExceptionFactory.java:38)
>  at 
> org.apache.jackrabbit.mk.blobs.AbstractBlobStore.readBlob(AbstractBlobStore.java:276)
>  at 
> org.apache.jackrabbit.mk.core.MicroKernelImpl.read(MicroKernelImpl.java:488)
>  ... 44 more
> Caused by: java.lang.IllegalArgumentException: SGVsbG8gd8O2cmxkLg==
>  at org.apache.jackrabbit.mk.util.StringUtils.getHexDigit(StringUtils.java:79)
>  at 
> org.

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273155#comment-13273155
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 65, Failures: 178

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-99) reading binary content fails for certain types of content

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272470#comment-13272470
 ] 

Julian Reschke commented on OAK-99:
---

It seems the failure has to do with the binary property being multivalued. We 
don't support that yet, right?

> reading binary content fails for certain types of content
> -
>
> Key: OAK-99
> URL: https://issues.apache.org/jira/browse/OAK-99
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mk
>Reporter: Julian Reschke
>
> With r1336746 I have added test content for export tests; and get the failure 
> below:
> org.apache.jackrabbit.mk.api.MicroKernelException: 
> org.apache.jackrabbit.mk.api.MicroKernelException: SGVsbG8gd8O2cmxkLg== 
>  at 
> org.apache.jackrabbit.mk.core.MicroKernelImpl.read(MicroKernelImpl.java:490)
>  at 
> org.apache.jackrabbit.mk.util.MicroKernelInputStream.read(MicroKernelInputStream.java:56)
>  at java.io.InputStream.read(Unknown Source)
>  at org.apache.jackrabbit.util.Base64.encode(Base64.java:156)
>  at org.apache.jackrabbit.value.ValueHelper.serialize(ValueHelper.java:681)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportValue(SystemViewExporter.java:129)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportProperty(SystemViewExporter.java:109)
>  at 
> org.apache.jackrabbit.commons.xml.Exporter.exportProperty(Exporter.java:361)
>  at 
> org.apache.jackrabbit.commons.xml.Exporter.exportProperties(Exporter.java:268)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:77)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
>  at 
> org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
>  at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
>  at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:143)
>  at 
> org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:548)
>  at 
> org.apache.jackrabbit.commons.AbstractSession.exportSystemView(AbstractSession.java:257)
>  at 
> org.apache.jackrabbit.test.api.ExportSysViewTest.doTestWithHandler(ExportSysViewTest.java:126)
>  at 
> org.apache.jackrabbit.test.api.ExportSysViewTest.testExportSysView_handler_session_saveBinary_recurse(ExportSysViewTest.java:94)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>  at java.lang.reflect.Method.invoke(Unknown Source)
>  at junit.framework.TestCase.runTest(TestCase.java:168)
>  at junit.framework.TestCase.runBare(TestCase.java:134)
>  at junit.framework.TestResult$1.protect(TestResult.java:110)
>  at junit.framework.TestResult.runProtected(TestResult.java:128)
>  at junit.framework.TestResult.run(TestResult.java:113)
>  at junit.framework.TestCase.run(TestCase.java:124)
>  at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456)
>  at junit.framework.TestSuite.runTest(TestSuite.java:243)
>  at junit.framework.TestSuite.run(TestSuite.java:238)
>  at junit.framework.TestSuite.runTest(TestSuite.java:243)
>  at junit.framework.TestSuite.run(TestSuite.java:238)
>  at junit.framework.TestSuite.runTest(TestSuite.java:243)
>  at 
> org.apache.jackrabbit.test.ConcurrentTestSuite.access$1(ConcurrentTestSuite.java:1)
>  at 
> org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67)
>  at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
>  at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.jackrabbit.mk.api.MicroKernelException: 
> SGVsbG8gd8O2cmxkLg== 
>  at 
> org.apache.jackrabbit.mk.util.ExceptionFactory.convert(ExceptionFactory.java:38)
>  at 
> org.apache.jackrabbit.mk.blobs.AbstractBlobStore.readBlob(AbstractBlobStore.java:276)
>  at 
> org.apache.jackrabbit.mk.core.MicroKernelImpl.read(MicroKernelImpl.java:488)
>  ... 44 more
> Caused by: java.lang.IllegalArgumentException: SGVsbG8gd8O2cmxkLg==
>  at org.apache.jackrabbit.mk.util.StringUtils.getHexDigit(StringUtils.java:79)
>  at 
> org.apach

[jira] [Created] (OAK-99) reading binary content fails for certain types of content

[Julian Reschke (JIRA)]

Julian Reschke created OAK-99:
-

 Summary: reading binary content fails for certain types of content
 Key: OAK-99
 URL: https://issues.apache.org/jira/browse/OAK-99
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mk
Reporter: Julian Reschke


With r1336746 I have added test content for export tests; and get the failure 
below:

org.apache.jackrabbit.mk.api.MicroKernelException: 
org.apache.jackrabbit.mk.api.MicroKernelException: SGVsbG8gd8O2cmxkLg== 
 at org.apache.jackrabbit.mk.core.MicroKernelImpl.read(MicroKernelImpl.java:490)
 at 
org.apache.jackrabbit.mk.util.MicroKernelInputStream.read(MicroKernelInputStream.java:56)
 at java.io.InputStream.read(Unknown Source)
 at org.apache.jackrabbit.util.Base64.encode(Base64.java:156)
 at org.apache.jackrabbit.value.ValueHelper.serialize(ValueHelper.java:681)
 at 
org.apache.jackrabbit.commons.xml.SystemViewExporter.exportValue(SystemViewExporter.java:129)
 at 
org.apache.jackrabbit.commons.xml.SystemViewExporter.exportProperty(SystemViewExporter.java:109)
 at org.apache.jackrabbit.commons.xml.Exporter.exportProperty(Exporter.java:361)
 at 
org.apache.jackrabbit.commons.xml.Exporter.exportProperties(Exporter.java:268)
 at 
org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:77)
 at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
 at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
 at 
org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
 at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
 at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
 at 
org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
 at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
 at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213)
 at 
org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78)
 at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294)
 at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:143)
 at 
org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:548)
 at 
org.apache.jackrabbit.commons.AbstractSession.exportSystemView(AbstractSession.java:257)
 at 
org.apache.jackrabbit.test.api.ExportSysViewTest.doTestWithHandler(ExportSysViewTest.java:126)
 at 
org.apache.jackrabbit.test.api.ExportSysViewTest.testExportSysView_handler_session_saveBinary_recurse(ExportSysViewTest.java:94)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at junit.framework.TestCase.runTest(TestCase.java:168)
 at junit.framework.TestCase.runBare(TestCase.java:134)
 at junit.framework.TestResult$1.protect(TestResult.java:110)
 at junit.framework.TestResult.runProtected(TestResult.java:128)
 at junit.framework.TestResult.run(TestResult.java:113)
 at junit.framework.TestCase.run(TestCase.java:124)
 at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456)
 at junit.framework.TestSuite.runTest(TestSuite.java:243)
 at junit.framework.TestSuite.run(TestSuite.java:238)
 at junit.framework.TestSuite.runTest(TestSuite.java:243)
 at junit.framework.TestSuite.run(TestSuite.java:238)
 at junit.framework.TestSuite.runTest(TestSuite.java:243)
 at 
org.apache.jackrabbit.test.ConcurrentTestSuite.access$1(ConcurrentTestSuite.java:1)
 at 
org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67)
 at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.jackrabbit.mk.api.MicroKernelException: 
SGVsbG8gd8O2cmxkLg== 
 at 
org.apache.jackrabbit.mk.util.ExceptionFactory.convert(ExceptionFactory.java:38)
 at 
org.apache.jackrabbit.mk.blobs.AbstractBlobStore.readBlob(AbstractBlobStore.java:276)
 at org.apache.jackrabbit.mk.core.MicroKernelImpl.read(MicroKernelImpl.java:488)
 ... 44 more
Caused by: java.lang.IllegalArgumentException: SGVsbG8gd8O2cmxkLg==
 at org.apache.jackrabbit.mk.util.StringUtils.getHexDigit(StringUtils.java:79)
 at 
org.apache.jackrabbit.mk.util.StringUtils.convertHexToBytes(StringUtils.java:58)
 at 
org.apache.jackrabbit.mk.blobs.AbstractBlobStore.readBlob(AbstractBlobStore.java:229)
 ... 45 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-95) path mapping needs to deal with relative paths

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-95.
---

   Resolution: Fixed
Fix Version/s: 0.3

> path mapping needs to deal with relative paths
> --
>
> Key: OAK-95
> URL: https://issues.apache.org/jira/browse/OAK-95
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 0.3
>
> Attachments: OAK-95.patch
>
>
> Persisting paths in properties of type "path" requires that we can round-trip 
> relative JCR paths through the oak-core persistence, such as
>   ../foobar
> or
>   .
> Note that these paths still need prefix remapping so that they are stable 
> with respect to session prefix remappings.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-95) path mapping needs to deal with relative paths

[Julian Reschke (JIRA)]

Julian Reschke created OAK-95:
-

 Summary: path mapping needs to deal with relative paths
 Key: OAK-95
 URL: https://issues.apache.org/jira/browse/OAK-95
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: Julian Reschke
Priority: Minor


Persisting paths in properties of type "path" requires that we can round-trip 
relative JCR paths through the oak-core persistence, such as

  ../foobar

or

  .

Note that these paths still need prefix remapping so that they are stable with 
respect to session prefix remappings.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272269#comment-13272269
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 45, Failures: 237

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271451#comment-13271451
 ] 

Julian Reschke commented on OAK-66:
---

I'm not sure about how to proceed from here.

It appears we need most of the code from spi2jcr's nodetype package (>4000 
lines of code). Is there an alternative to copying and changing it for the Oak 
internal APIs? Maintaining this kind of code twice (or even three times) within 
a single Apache project doesn't seem to be such as good idea...

> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>Assignee: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned OAK-66:
-

Assignee: (was: Julian Reschke)

> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-37) Use nullability annotation to enforce/document API contract

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271355#comment-13271355
 ] 

Julian Reschke commented on OAK-37:
---

I just checked with FindBugs 2.01, and annotating methods with @CheckForNull 
and @Nonnull seemed to have the desired effect.

That being said, this appears to be a can of worms; JSR-305 is dormant; 
FindBugs supports the annotation using it's own package + javax.annotation.

IntelliJ is said to support them in "all" packages, but I can't test that.

There's also a Eclipse JDT extension in the works which appears to be 
configurable with respect to package names 
(http://wiki.eclipse.org/JDT_Core/Null_Analysis)

In the end we need something that has an acceptable license, and can be 
automatically checked; FindBugs is probably a candidate for that.


> Use nullability annotation to enforce/document API contract
> ---
>
> Key: OAK-37
> URL: https://issues.apache.org/jira/browse/OAK-37
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr, mk
>Reporter: Michael Dürig
>
> In a discussion about exception handling on the dev list [1] Julian brough up 
> the idea of using nullability annotations in APIs. I think we should decide 
> on which one to use and start using them whereever apropriate. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-89) Improve exception handling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271321#comment-13271321
 ] 

Julian Reschke commented on OAK-89:
---

bq. Sounds like a good idea to me.

I'll try the latest FindBugs right now.

> Improve exception handling
> --
>
> Key: OAK-89
> URL: https://issues.apache.org/jira/browse/OAK-89
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr
>Affects Versions: 0.2.1
>Reporter: Michael Dürig
> Attachments: OAK-89-2.patch, OAK-89.patch, OAK-89.patch
>
>
> As discusses on the @oak-dev list [1] we need to improve the way exceptions 
> are thrown and handled. 
> I suggest to create a OakException which extends from RuntimeException and 
> encapsulate a RepositoryException into it. These exceptions can then be 
> handled where appropriate. We can the later turn this into a more 
> sophisticated mechanism where the OakException is mapped to a corresponding 
> RepositoryException by an injected mapping (see Jukka's proposal in the 
> discussion).
> [1] http://markmail.org/message/t5czrpkvyamn7sym

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271314#comment-13271314
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 171, Failures: 154

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270405#comment-13270405
 ] 

Julian Reschke commented on OAK-66:
---

Status:

- CND is now read using JCR commons parser; name mapping currently does not 
happen
- the registry is read-only
- checker methods aren't implemented yet.

Next step:

- split implementation classes into session-aware variants and delegates
- implement checker methods (code can probably be adopted from existing 
jackrabbit code)

Future steps:

- persist node type information in content (at that point we will use CND just 
for import/export)
- move low level classes to a location where they can be used from oak-core for 
validation


> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>Assignee: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270348#comment-13270348
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 172, Failures: 155

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-89) Improve exception handling

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269918#comment-13269918
 ] 

Julian Reschke commented on OAK-89:
---

When I proposed this I was under the assumption that the "avoid checked 
exceptions" pattern was the consensus already.

It seems that this wasn't the case, so I'd like to point out that I actually 
prefer checked exceptions -- when they make sense -- as well.



> Improve exception handling
> --
>
> Key: OAK-89
> URL: https://issues.apache.org/jira/browse/OAK-89
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr
>Affects Versions: 0.2.1
>Reporter: Michael Dürig
>
> As discusses on the @oak-dev list [1] we need to improve the way exceptions 
> are thrown and handled. 
> I suggest to create a OakException which extends from RuntimeException and 
> encapsulate a RepositoryException into it. These exceptions can then be 
> handled where appropriate. We can the later turn this into a more 
> sophisticated mechanism where the OakException is mapped to a corresponding 
> RepositoryException by an injected mapping (see Jukka's proposal in the 
> discussion).
> [1] http://markmail.org/message/t5czrpkvyamn7sym

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269548#comment-13269548
 ] 

Julian Reschke commented on OAK-6:
--

TCK status: Tests: 1905, Errors: 222, Failures: 499

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-6) Setup integration tests and TCK tests

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268487#comment-13268487
 ] 

Julian Reschke commented on OAK-6:
--

TCK status 2012-05-04: Tests: 1905, Errors: 223, Failures: 501

> Setup integration tests and TCK tests
> -
>
> Key: OAK-6
> URL: https://issues.apache.org/jira/browse/OAK-6
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: it
>Reporter: Michael Dürig
>  Labels: test
> Fix For: 0.1
>
>
> See discussion here [1] and here [2]
> [1] 
> http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29
> [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-66) JCR Node Type Management

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned OAK-66:
-

Assignee: Julian Reschke

> JCR Node Type Management
> 
>
> Key: OAK-66
> URL: https://issues.apache.org/jira/browse/OAK-66
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, jcr
>Reporter: angela
>Assignee: Julian Reschke
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-84) Delegates for Session, Node, Property and Item

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267626#comment-13267626
 ] 

Julian Reschke commented on OAK-84:
---

But there is no other way to find out whether two sessions are the same. I 
think it's good that it can be checked.

> Delegates for Session, Node, Property and Item
> --
>
> Key: OAK-84
> URL: https://issues.apache.org/jira/browse/OAK-84
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Reporter: Michael Dürig
>
> Instead of passing around Nodes internally and casting them down to NodeImpl 
> we should use the façade pattern and delegate from NodeImpl back to an 
> implementation class which is used internally. This also avoids the problem 
> of API clients accessing stuff they shouldn't by casting to the 
> implementation. 
> Some initial work has been done already. What's left to do it: 
> * Push down as much as possible from ItemImpl, NodeImpl and PropertyImpl to 
> the respective delegate classes
> * Introduce the same pattern for SessionImpl and do away with SessionContext. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-84) Delegates for Session, Node, Property and Item

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267582#comment-13267582
 ] 

Julian Reschke commented on OAK-84:
---

The prose in the spec doesn't seem to say. Item.getSession's javadoc doesn't 
help either. But Workspace.getSession's javadoc says "return the Session 
*object* ...".



> Delegates for Session, Node, Property and Item
> --
>
> Key: OAK-84
> URL: https://issues.apache.org/jira/browse/OAK-84
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Reporter: Michael Dürig
>
> Instead of passing around Nodes internally and casting them down to NodeImpl 
> we should use the façade pattern and delegate from NodeImpl back to an 
> implementation class which is used internally. This also avoids the problem 
> of API clients accessing stuff they shouldn't by casting to the 
> implementation. 
> Some initial work has been done already. What's left to do it: 
> * Push down as much as possible from ItemImpl, NodeImpl and PropertyImpl to 
> the respective delegate classes
> * Introduce the same pattern for SessionImpl and do away with SessionContext. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira