[jira] [Commented] (OAK-7676) Build Jackrabbit Oak #1582 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7676:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1591|https://builds.apache.org/job/Jackrabbit%20Oak/1591/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1591/console]

> Build Jackrabbit Oak #1582 failed
> -
>
> Key: OAK-7676
> URL: https://issues.apache.org/jira/browse/OAK-7676
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1582 has failed.
> First failed run: [Jackrabbit Oak 
> #1582|https://builds.apache.org/job/Jackrabbit%20Oak/1582/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1582/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7679:
-

trunk: [r1837569|http://svn.apache.org/r1837569]

> oak-core: update Mockito version and fix test case to be compatible with it
> ---
>
> Key: OAK-7679
> URL: https://issues.apache.org/jira/browse/OAK-7679
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
> Attachments: OAK-7679.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-7679.
-
   Resolution: Fixed
Fix Version/s: 1.9.7
   1.10

> oak-core: update Mockito version and fix test case to be compatible with it
> ---
>
> Key: OAK-7679
> URL: https://issues.apache.org/jira/browse/OAK-7679
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
> Attachments: OAK-7679.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7679:

Labels: candidate_oak_1_8  (was: )

> oak-core: update Mockito version and fix test case to be compatible with it
> ---
>
> Key: OAK-7679
> URL: https://issues.apache.org/jira/browse/OAK-7679
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
> Attachments: OAK-7679.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 11:22 PM:
-

Option 1 also has 3 different levels if you look at it in detail. From less 
complete (a) to full complete (c):
 * *a)* Fix just the immediate case in oak-jcr and oak-core as done by Matt in 
[this 
branch|https://github.com/mattvryan/jackrabbit-oak/tree/direct-binary-access-v2-with-create-binary-value-fix]
 ** Addresses the normal {{getProperty().getBinary()}} and 
{{getProperty().getValue().getBinary()}} usages plus multi-value binary 
properties.
 ** I would do the changes slightly differently and just replace all static 
method usage outside ValueFactoryImpl, where possible.
 ** Con: Leaves open {{ValueFactoryImpl.createValue()}} static method usage in 
12 files (3 of which are in tests), with unknown impact.
 * *b)* Same as a) but also change the {{createValue()}} usage in all code 
paths that don't actually use a {{NamePathMapper.DEFAULT}} and don't have 
access to a {{SessionContext}} currently
 ** No exact numbers, but {{NamePathMapper}} is used in 104 files, and 62 use 
{{NamePathMapper.DEFAULT}}. Some might be from different uses of this interface.
 ** A trick and arguable a hack for this case could be to repurpose 
{{NamePathMapper}} and add a new interface method {{getInternalValueFactory()}} 
to it, which would return {{ValueFactoryImpl}} (or a new internal interface). 
In some / most cases the {{NamePathMapper}} is actually the {{SessionContext}}, 
and this would be simple to do. The API semantics of {{NamePathMapper}} would 
be a bit confusing, but at least it would prevent one from changing all the 
methods and classes that pass around {{NamePathMapper}} to pass around 
something else.
 ** Con: This leaves open places that end up using {{NamePathMapper.DEFAULT}}.
 * *c)* Rigorously ensure everyone using a {{ValueFactoryImpl}} static method 
must use an instance, and must have access to the current {{SessionContext}} or 
{{SessionImpl}}, and remove use of {{NamePathMapper.DEFAULT}}
 ** Would surely be a useful improvement.
 ** Con: Seems like a massive Oak change as mentioned above.

Note that places (at runtime, not tests) that use {{NamePathMapper.DEFAULT}} 
today would have at least the limitation that when a NAME or PATH property is 
used, and the session has local namespaces, that these aren't respected, 
because the default impl has no access to them.


was (Author: alexander.klimetschek):
Option 1 also has 3 different levels if you look at it in detail. From less 
complete (a) to full complete (c):
 * *a)* Fix just the immediate case in oak-jcr and oak-core as done by Matt in 
[this 
PR|https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]
 (linked in my long comment above already)
 ** Addresses the normal {{getProperty().getBinary()}} and 
{{getProperty().getValue().getBinary()}} usages plus multi-value binary 
properties.
 ** I would do the changes slightly differently and just replace all static 
method usage outside ValueFactoryImpl, where possible.
 ** Con: Leaves open {{ValueFactoryImpl.createValue()}} static method usage in 
12 files (3 of which are in tests), with unknown impact.
 * *b)* Same as a) but also change the {{createValue()}} usage in all code 
paths that don't actually use a {{NamePathMapper.DEFAULT}} and don't have 
access to a {{SessionContext}} currently
 ** No exact numbers, but {{NamePathMapper}} is used in 104 files, and 62 use 
{{NamePathMapper.DEFAULT}}. Some might be from different uses of this interface.
 ** A trick and arguable a hack for this case could be to repurpose 
{{NamePathMapper}} and add a new interface method {{getInternalValueFactory()}} 
to it, which would return {{ValueFactoryImpl}} (or a new internal interface). 
In some / most cases the {{NamePathMapper}} is actually the {{SessionContext}}, 
and this would be simple to do. The API semantics of {{NamePathMapper}} would 
be a bit confusing, but at least it would prevent one from changing all the 
methods and classes that pass around {{NamePathMapper}} to pass around 
something else.
 ** Con: This leaves open places that end up using {{NamePathMapper.DEFAULT}}.
 * *c)* Rigorously ensure everyone using a {{ValueFactoryImpl}} static method 
must use an instance, and must have access to the current {{SessionContext}} or 
{{SessionImpl}}, and remove use of {{NamePathMapper.DEFAULT}}
 ** Would surely be a useful improvement.
 ** Con: Seems like a massive Oak change as mentioned above.

Note that places (at runtime, not tests) that use {{NamePathMapper.DEFAULT}} 
today would have at least the limitation that when a NAME or PATH property is 
used, and the session has local namespaces, that these aren't respected, 
because the default impl has no access to them.

> 

[jira] [Assigned] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned OAK-7679:
---

Assignee: Julian Reschke

> oak-core: update Mockito version and fix test case to be compatible with it
> ---
>
> Key: OAK-7679
> URL: https://issues.apache.org/jira/browse/OAK-7679
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-7679.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7685) Update easymock dependency to 3.6

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7685:
-

trunk: [r1837547|http://svn.apache.org/r1837547]


> Update easymock dependency to 3.6
> -
>
> Key: OAK-7685
> URL: https://issues.apache.org/jira/browse/OAK-7685
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7685) Update easymock dependency to 3.6

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-7685.
-
   Resolution: Fixed
Fix Version/s: 1.9.7

> Update easymock dependency to 3.6
> -
>
> Key: OAK-7685
> URL: https://issues.apache.org/jira/browse/OAK-7685
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7685) Update easymock dependency to 3.6

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7685:

Labels: candidate_oak_1_8  (was: )

> Update easymock dependency to 3.6
> -
>
> Key: OAK-7685
> URL: https://issues.apache.org/jira/browse/OAK-7685
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7685) Update easymock dependency to 3.6

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7685:
---

 Summary: Update easymock dependency to 3.6
 Key: OAK-7685
 URL: https://issues.apache.org/jira/browse/OAK-7685
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: parent
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.10






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:25 PM:


Option 1 also has 3 different levels if you look at it in detail. From less 
complete (a) to full complete (c):
 * *a)* Fix just the immediate case in oak-jcr and oak-core as done by Matt in 
[this 
PR|https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]
 (linked in my long comment above already)
 ** Addresses the normal {{getProperty().getBinary()}} and 
{{getProperty().getValue().getBinary()}} usages plus multi-value binary 
properties.
 ** I would do the changes slightly differently and just replace all static 
method usage outside ValueFactoryImpl, where possible.
 ** Con: Leaves open {{ValueFactoryImpl.createValue()}} static method usage in 
12 files (3 of which are in tests), with unknown impact.
 * *b)* Same as a) but also change the {{createValue()}} usage in all code 
paths that don't actually use a {{NamePathMapper.DEFAULT}} and don't have 
access to a {{SessionContext}} currently
 ** No exact numbers, but {{NamePathMapper}} is used in 104 files, and 62 use 
{{NamePathMapper.DEFAULT}}. Some might be from different uses of this interface.
 ** A trick and arguable a hack for this case could be to repurpose 
{{NamePathMapper}} and add a new interface method {{getInternalValueFactory()}} 
to it, which would return {{ValueFactoryImpl}} (or a new internal interface). 
In some / most cases the {{NamePathMapper}} is actually the {{SessionContext}}, 
and this would be simple to do. The API semantics of {{NamePathMapper}} would 
be a bit confusing, but at least it would prevent one from changing all the 
methods and classes that pass around {{NamePathMapper}} to pass around 
something else.
 ** Con: This leaves open places that end up using {{NamePathMapper.DEFAULT}}.
 * *c)* Rigorously ensure everyone using a {{ValueFactoryImpl}} static method 
must use an instance, and must have access to the current {{SessionContext}} or 
{{SessionImpl}}, and remove use of {{NamePathMapper.DEFAULT}}
 ** Would surely be a useful improvement.
 ** Con: Seems like a massive Oak change as mentioned above.

Note that places (at runtime, not tests) that use {{NamePathMapper.DEFAULT}} 
today would have at least the limitation that when a NAME or PATH property is 
used, and the session has local namespaces, that these aren't respected, 
because the default impl has no access to them.


was (Author: alexander.klimetschek):
Option 1 also has 3 different levels if you look at it in detail. From less 
complete (a) to full complete (c):
 * *a)* Fix just the immediate case in oak-jcr and oak-core as done by Matt in 
[this 
PR|https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]
 (linked in my long comment above already)
 ** Addresses the normal {{getProperty().getBinary()}} and 
{{getProperty().getValue().getBinary()}} usages plus multi-value binary 
properties.
 ** I would do the changes slightly differently and just replace all static 
method usage outside ValueFactoryImpl, where possible.
 ** Con: Leaves open {{ValueFactoryImpl.createValue()}} static method usage in 
12 files (3 of which are in tests), with unknown impact.
 * *b)* Same as a) but also change the createValue() usage in all code paths 
that don't start with a NamePathMapper.DEFAULT and don't have access to a 
SessionContext currently
 ** No exact numbers, but NamePathMapper is used in 104 files, and 62 use 
{{NamePathMapper.DEFAULT}}.
 ** A trick and arguable a hack for this case could be to repurpose 
{{NamePathMapper}} and add a new interface method {{getInternalValueFactory()}} 
to it, which would return {{ValueFactoryImpl}} (or a new internal interface). 
In some / most cases the {{NamePathMapper}} is actually the {{SessionContext}}, 
and this would be simple to do. The API semantics of {{NamePathMapper}} would 
be a bit confusing, but at least it would prevent one from changing all the 
methods and classes that pass around {{NamePathMapper}} to pass around 
something else.
 ** Con: This leaves open places that end up using {{NamePathMapper.DEFAULT}}.
 * *c)* Rigorously ensure everyone using a {{ValueFactoryImpl}} static method 
must use an instance, and must have access to the current {{SessionContext}} or 
{{SessionImpl}}, and remove use of {{NamePathMapper.DEFAULT}}
 ** Would surely be a useful improvement.
 ** Con: Seems like a massive Oak change as mentioned above.

Note that places (at runtime, not tests) that use {{NamePathMapper.DEFAULT}} 
today would have at least the limitation that when a NAME or PATH property is 
used, and the session has local namespaces, that these aren't respected, 
because the default impl has no access to them.

> Direct Binary Access
> 
>
>  

[jira] [Commented] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on OAK-7569:


Option 1 also has 3 different levels if you look at it in detail. From less 
complete (a) to full complete (c):
 * *a)* Fix just the immediate case in oak-jcr and oak-core as done by Matt in 
[this 
PR|https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]
 (linked in my long comment above already)
 ** Addresses the normal {{getProperty().getBinary()}} and 
{{getProperty().getValue().getBinary()}} usages plus multi-value binary 
properties.
 ** I would do the changes slightly differently and just replace all static 
method usage outside ValueFactoryImpl, where possible.
 ** Con: Leaves open {{ValueFactoryImpl.createValue()}} static method usage in 
12 files (3 of which are in tests), with unknown impact.
 * *b)* Same as a) but also change the createValue() usage in all code paths 
that don't start with a NamePathMapper.DEFAULT and don't have access to a 
SessionContext currently
 ** No exact numbers, but NamePathMapper is used in 104 files, and 62 use 
{{NamePathMapper.DEFAULT}}.
 ** A trick and arguable a hack for this case could be to repurpose 
{{NamePathMapper}} and add a new interface method {{getInternalValueFactory()}} 
to it, which would return {{ValueFactoryImpl}} (or a new internal interface). 
In some / most cases the {{NamePathMapper}} is actually the {{SessionContext}}, 
and this would be simple to do. The API semantics of {{NamePathMapper}} would 
be a bit confusing, but at least it would prevent one from changing all the 
methods and classes that pass around {{NamePathMapper}} to pass around 
something else.
 ** Con: This leaves open places that end up using {{NamePathMapper.DEFAULT}}.
 * *c)* Rigorously ensure everyone using a {{ValueFactoryImpl}} static method 
must use an instance, and must have access to the current {{SessionContext}} or 
{{SessionImpl}}, and remove use of {{NamePathMapper.DEFAULT}}
 ** Would surely be a useful improvement.
 ** Con: Seems like a massive Oak change as mentioned above.

Note that places (at runtime, not tests) that use {{NamePathMapper.DEFAULT}} 
today would have at least the limitation that when a NAME or PATH property is 
used, and the session has local namespaces, that these aren't respected, 
because the default impl has no access to them.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7676) Build Jackrabbit Oak #1582 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7676:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1589|https://builds.apache.org/job/Jackrabbit%20Oak/1589/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1589/console]

> Build Jackrabbit Oak #1582 failed
> -
>
> Key: OAK-7676
> URL: https://issues.apache.org/jira/browse/OAK-7676
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1582 has failed.
> First failed run: [Jackrabbit Oak 
> #1582|https://builds.apache.org/job/Jackrabbit%20Oak/1582/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1582/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7676) Build Jackrabbit Oak #1582 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7676:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1588|https://builds.apache.org/job/Jackrabbit%20Oak/1588/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1588/console]

> Build Jackrabbit Oak #1582 failed
> -
>
> Key: OAK-7676
> URL: https://issues.apache.org/jira/browse/OAK-7676
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1582 has failed.
> First failed run: [Jackrabbit Oak 
> #1582|https://builds.apache.org/job/Jackrabbit%20Oak/1582/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1582/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 2:57 PM:


Sure, but please note that getting the implementation right (getting rid of 
static ValueFactoryImpl usage) affects 100+ files. Searching for NamePathMapper 
gives an indication: 
https://github.com/apache/jackrabbit-oak/search?utf8=%E2%9C%93=NamePathMapper

This would involve folks from different parts of Oak and possible take weeks 
and introduce a lot of risks.

Matt and me really looked into that last week but had to give up - especially 
when you hit NamePathMapper.DEFAULT. I fully agree it would be good for Oak to 
straighten this, but I guess there is a limit to what amount can be refactored 
and it would be nice to finally get this feature in.


was (Author: alexander.klimetschek):
Sure, but please note that getting the implementation right (getting rid of 
static ValueFactoryImpl usage) affects 100+ files. Searching for NamePathMapper 
gives an indication: 
https://github.com/apache/jackrabbit-oak/search?utf8=%E2%9C%93=NamePathMapper

This would involve folks from different parts of Oak and possible take weeks 
and introduce a lot of risks.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7676) Build Jackrabbit Oak #1582 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7676:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1587|https://builds.apache.org/job/Jackrabbit%20Oak/1587/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1587/console]

> Build Jackrabbit Oak #1582 failed
> -
>
> Key: OAK-7676
> URL: https://issues.apache.org/jira/browse/OAK-7676
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1582 has failed.
> First failed run: [Jackrabbit Oak 
> #1582|https://builds.apache.org/job/Jackrabbit%20Oak/1582/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1582/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on OAK-7679:
--

+1

> oak-core: update Mockito version and fix test case to be compatible with it
> ---
>
> Key: OAK-7679
> URL: https://issues.apache.org/jira/browse/OAK-7679
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7679.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on OAK-7569:


Sure, but please note that getting the implementation right (getting rid of 
static ValueFactoryImpl usage) affects 100+ files. Searching for NamePathMapper 
gives an indication: 
https://github.com/apache/jackrabbit-oak/search?utf8=%E2%9C%93=NamePathMapper

This would involve folks from different parts of Oak and possible take weeks 
and introduce a lot of risks.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (OAK-7684) fix maven warnings on oak-solr-osgi

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned OAK-7684:
---

Assignee: Tommaso Teofili  (was: Julian Reschke)

> fix maven warnings on oak-solr-osgi
> ---
>
> Key: OAK-7684
> URL: https://issues.apache.org/jira/browse/OAK-7684
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: 1.10
>
>
> {noformat}
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/InStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/OutStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/CoordinateSequenceFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/GeometryFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> Unused Import-Package instructions: [com.sun.*]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (OAK-7684) fix maven warnings on oak-solr-osgi

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned OAK-7684:
---

Assignee: Julian Reschke

> fix maven warnings on oak-solr-osgi
> ---
>
> Key: OAK-7684
> URL: https://issues.apache.org/jira/browse/OAK-7684
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
>
> {noformat}
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/InStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/OutStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/CoordinateSequenceFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/GeometryFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> Unused Import-Package instructions: [com.sun.*]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7684) fix maven warnings on oak-solr-osgi

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7684:

Fix Version/s: 1.10

> fix maven warnings on oak-solr-osgi
> ---
>
> Key: OAK-7684
> URL: https://issues.apache.org/jira/browse/OAK-7684
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
>
> {noformat}
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/InStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/OutStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/CoordinateSequenceFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/GeometryFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> Unused Import-Package instructions: [com.sun.*]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7684) fix maven warnings on oak-solr-osgi

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7684:
---

 Summary: fix maven warnings on oak-solr-osgi
 Key: OAK-7684
 URL: https://issues.apache.org/jira/browse/OAK-7684
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: solr
Reporter: Julian Reschke


{noformat}
[WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
NoClassDefFoundError: com/vividsolutions/jts/io/InStream
[WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
NoClassDefFoundError: com/vividsolutions/jts/io/OutStream
[WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
NoClassDefFoundError: com/vividsolutions/jts/geom/CoordinateSequenceFilter
[WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
NoClassDefFoundError: com/vividsolutions/jts/geom/GeometryFilter
[WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
Unused Import-Package instructions: [com.sun.*]
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7683) fix maven warnings on search-mt

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7683:
---

 Summary: fix maven warnings on search-mt
 Key: OAK-7683
 URL: https://issues.apache.org/jira/browse/OAK-7683
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: search-mt
Reporter: Julian Reschke
Assignee: Tommaso Teofili


{noformat}
[WARNING] Bundle org.apache.jackrabbit:oak-search-mt:bundle:1.10-SNAPSHOT : 
NoClassDefFoundError: edu/uci/ics/jung/graph/DirectedOrderedSparseMultigraph
[WARNING] Bundle org.apache.jackrabbit:oak-search-mt:bundle:1.10-SNAPSHOT : 
NoClassDefFoundError: org/apache/commons/collections15/Transformer
[WARNING] Bundle org.apache.jackrabbit:oak-search-mt:bundle:1.10-SNAPSHOT : 
NoClassDefFoundError: edu/uci/ics/jung/visualization/VisualizationViewer
[WARNING] Bundle org.apache.jackrabbit:oak-search-mt:bundle:1.10-SNAPSHOT : 
Unused Import-Package instructions: [com.ibm.uvm.tools.*, com.sun.jdmk.comm.*, 
javax.jms.*, javax.jmdns.*, junit.framework.*, org.apache.tools.ant.*, 
org.apache.tools.ant.types.*, org.easymock.*, org.jmock.core.*]
{noformat}

Seems that these were introduced by the major pom changes for OAK-6837 in 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-3336:
-

Adjusted baseline check in [r1837519|http://svn.apache.org/r1837519]

> Abstract a full text index implementation to be extended by Lucene and Solr
> ---
>
> Key: OAK-3336
> URL: https://issues.apache.org/jira/browse/OAK-3336
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene, query, solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.10
>
>
> Current Lucene and Solr indexes implement quite a no. of features according 
> to their specific APIs, design and implementation. However in the long run, 
> while differences in APIs and implementations will / can of course stay, the 
> difference in design can make it hard to keep those features on par.
> It'd be therefore nice to make it possible to abstract as much of design and 
> implementation bits as possible in an abstract full text implementation which 
> Lucene and Solr would extend according to their specifics.
> An example advantage of this is that index time aggregation will be 
> implemented only once and therefore any bugfixes and improvements in that 
> area will be done in the abstract implementation rather than having to do 
> that in two places.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7682) fix comparisonVersion for baseline check

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7682:
-

trunk: [r1837518|http://svn.apache.org/r1837518]

> fix comparisonVersion for baseline check
> 
>
> Key: OAK-7682
> URL: https://issues.apache.org/jira/browse/OAK-7682
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7682) fix comparisonVersion for baseline check

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-7682.
-
   Resolution: Fixed
Fix Version/s: 1.9.7

> fix comparisonVersion for baseline check
> 
>
> Key: OAK-7682
> URL: https://issues.apache.org/jira/browse/OAK-7682
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7681) enable baseline check for oak-search-mt

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-7681.
-
   Resolution: Fixed
Fix Version/s: 1.9.7

> enable baseline check for oak-search-mt
> ---
>
> Key: OAK-7681
> URL: https://issues.apache.org/jira/browse/OAK-7681
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: search-mt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10, 1.9.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7681) enable baseline check for oak-search-mt

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7681:
-

trunk: [r1837517|http://svn.apache.org/r1837517]


> enable baseline check for oak-search-mt
> ---
>
> Key: OAK-7681
> URL: https://issues.apache.org/jira/browse/OAK-7681
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: search-mt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10, 1.9.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7682) fix comparisonVersion for baseline check

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7682:
---

 Summary: fix comparisonVersion for baseline check
 Key: OAK-7682
 URL: https://issues.apache.org/jira/browse/OAK-7682
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: parent
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.10






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7681) enable baseline check for oak-search-mt

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7681:

Summary: enable baseline check for oak-search-mt  (was: enable baseline 
check for oak-search and oak-search-mt)

> enable baseline check for oak-search-mt
> ---
>
> Key: OAK-7681
> URL: https://issues.apache.org/jira/browse/OAK-7681
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: search-mt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7676) Build Jackrabbit Oak #1582 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7676:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1586|https://builds.apache.org/job/Jackrabbit%20Oak/1586/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1586/console]

> Build Jackrabbit Oak #1582 failed
> -
>
> Key: OAK-7676
> URL: https://issues.apache.org/jira/browse/OAK-7676
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1582 has failed.
> First failed run: [Jackrabbit Oak 
> #1582|https://builds.apache.org/job/Jackrabbit%20Oak/1582/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1582/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7681) enable baseline check for oak-search and oak-search-mt

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7681:
---

 Summary: enable baseline check for oak-search and oak-search-mt
 Key: OAK-7681
 URL: https://issues.apache.org/jira/browse/OAK-7681
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: search-mt
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.10






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7680) oak-commons: upgrade to project default mockito version

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7680:
-

See , 
[~mreutegg] please review...

> oak-commons: upgrade to project default mockito version
> ---
>
> Key: OAK-7680
> URL: https://issues.apache.org/jira/browse/OAK-7680
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: commons
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7680.diff
>
>
> Unfortunately, mocking varargs seems to work different in current mockito 
> versions. With the 2:* default from the parent pom, I'm getting the test 
> failure below:
> {noformat}
> [ERROR] Tests run: 12, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 
> 0.828 s <<< FAILURE! - in org.apache.jackrabbit.oak.commons.PerfLoggerTest
> [ERROR] 
> logAtDebugMessageStartWithInfoLog(org.apache.jackrabbit.oak.commons.PerfLoggerTest)
>   Time elapsed: 0.045 s  <<< FAILURE!
> org.mockito.exceptions.verification.junit.ArgumentsAreDifferent:
> Argument(s) are different! Wanted:
> logger.debug(
> ,
> 
> );
> -> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
> Actual invocation has different arguments:
> logger.debug(
> "message [took 0ms]",
> "argument"
> );
> -> at org.apache.jackrabbit.oak.commons.PerfLogger.end(PerfLogger.java:223)
> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.logAtDebugMessageStartWithInfoLog(PerfLoggerTest.java:144)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7680) oak-commons: upgrade to project default mockito version

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7680:

Attachment: OAK-7680.diff

> oak-commons: upgrade to project default mockito version
> ---
>
> Key: OAK-7680
> URL: https://issues.apache.org/jira/browse/OAK-7680
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: commons
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7680.diff
>
>
> Unfortunately, mocking varargs seems to work different in current mockito 
> versions. With the 2:* default from the parent pom, I'm getting the test 
> failure below:
> {noformat}
> [ERROR] Tests run: 12, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 
> 0.828 s <<< FAILURE! - in org.apache.jackrabbit.oak.commons.PerfLoggerTest
> [ERROR] 
> logAtDebugMessageStartWithInfoLog(org.apache.jackrabbit.oak.commons.PerfLoggerTest)
>   Time elapsed: 0.045 s  <<< FAILURE!
> org.mockito.exceptions.verification.junit.ArgumentsAreDifferent:
> Argument(s) are different! Wanted:
> logger.debug(
> ,
> 
> );
> -> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
> Actual invocation has different arguments:
> logger.debug(
> "message [took 0ms]",
> "argument"
> );
> -> at org.apache.jackrabbit.oak.commons.PerfLogger.end(PerfLogger.java:223)
> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.logAtDebugMessageStartWithInfoLog(PerfLoggerTest.java:144)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7680) oak-commons: upgrade to project default mockito version

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7680:

Description: 
Unfortunately, mocking varargs seems to work different in current mockito 
versions. With the 2:* default from the parent pom, I'm getting the test 
failure below:
{noformat}
[ERROR] Tests run: 12, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 0.828 
s <<< FAILURE! - in org.apache.jackrabbit.oak.commons.PerfLoggerTest
[ERROR] 
logAtDebugMessageStartWithInfoLog(org.apache.jackrabbit.oak.commons.PerfLoggerTest)
  Time elapsed: 0.045 s  <<< FAILURE!
org.mockito.exceptions.verification.junit.ArgumentsAreDifferent:

Argument(s) are different! Wanted:
logger.debug(
,

);
-> at 
org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
Actual invocation has different arguments:
logger.debug(
"message [took 0ms]",
"argument"
);
-> at org.apache.jackrabbit.oak.commons.PerfLogger.end(PerfLogger.java:223)

at 
org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
at 
org.apache.jackrabbit.oak.commons.PerfLoggerTest.logAtDebugMessageStartWithInfoLog(PerfLoggerTest.java:144)


{noformat}

> oak-commons: upgrade to project default mockito version
> ---
>
> Key: OAK-7680
> URL: https://issues.apache.org/jira/browse/OAK-7680
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: commons
>Reporter: Julian Reschke
>Priority: Minor
>
> Unfortunately, mocking varargs seems to work different in current mockito 
> versions. With the 2:* default from the parent pom, I'm getting the test 
> failure below:
> {noformat}
> [ERROR] Tests run: 12, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 
> 0.828 s <<< FAILURE! - in org.apache.jackrabbit.oak.commons.PerfLoggerTest
> [ERROR] 
> logAtDebugMessageStartWithInfoLog(org.apache.jackrabbit.oak.commons.PerfLoggerTest)
>   Time elapsed: 0.045 s  <<< FAILURE!
> org.mockito.exceptions.verification.junit.ArgumentsAreDifferent:
> Argument(s) are different! Wanted:
> logger.debug(
> ,
> 
> );
> -> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
> Actual invocation has different arguments:
> logger.debug(
> "message [took 0ms]",
> "argument"
> );
> -> at org.apache.jackrabbit.oak.commons.PerfLogger.end(PerfLogger.java:223)
> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.verifyDebugInteractions(PerfLoggerTest.java:227)
> at 
> org.apache.jackrabbit.oak.commons.PerfLoggerTest.logAtDebugMessageStartWithInfoLog(PerfLoggerTest.java:144)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7680) oak-commons: upgrade to project default mockito version

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7680:
---

 Summary: oak-commons: upgrade to project default mockito version
 Key: OAK-7680
 URL: https://issues.apache.org/jira/browse/OAK-7680
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: commons
Reporter: Julian Reschke






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7679:
-

Proposed patch in 
 - 
[~chetanm]: should I commit that?

> oak-core: update Mockito version and fix test case to be compatible with it
> ---
>
> Key: OAK-7679
> URL: https://issues.apache.org/jira/browse/OAK-7679
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7679.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7679:

Attachment: OAK-7679.diff

> oak-core: update Mockito version and fix test case to be compatible with it
> ---
>
> Key: OAK-7679
> URL: https://issues.apache.org/jira/browse/OAK-7679
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7679.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7679) oak-core: update Mockito version and fix test case to be compatible with it

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7679:
---

 Summary: oak-core: update Mockito version and fix test case to be 
compatible with it
 Key: OAK-7679
 URL: https://issues.apache.org/jira/browse/OAK-7679
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: core
Reporter: Julian Reschke






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7678) Update to default mockito version (defined in oak-parent)

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-7678.
-
Resolution: Fixed

> Update to default mockito version (defined in oak-parent)
> -
>
> Key: OAK-7678
> URL: https://issues.apache.org/jira/browse/OAK-7678
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: authorization-cug, blob-cloud, blob-cloud-azure, 
> blob-plugins, core-spi, it, lucene, pojosr, query, run, search-mt, 
> segment-tar, segmentmk, solr, store-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>
> ...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7678) Update to default mockito version (defined in oak-parent)

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7678:
-

trunk: [r1837503|http://svn.apache.org/r1837503]


> Update to default mockito version (defined in oak-parent)
> -
>
> Key: OAK-7678
> URL: https://issues.apache.org/jira/browse/OAK-7678
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: authorization-cug, blob-cloud, blob-cloud-azure, 
> blob-plugins, core-spi, it, lucene, pojosr, query, run, search-mt, 
> segment-tar, segmentmk, solr, store-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>
> ...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7678) Update to default mockito version (defined in oak-parent)

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7678:

Fix Version/s: 1.9.7

> Update to default mockito version (defined in oak-parent)
> -
>
> Key: OAK-7678
> URL: https://issues.apache.org/jira/browse/OAK-7678
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: authorization-cug, blob-cloud, blob-cloud-azure, 
> blob-plugins, core-spi, it, lucene, pojosr, query, run, search-mt, 
> segment-tar, segmentmk, solr, store-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>
> ...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7678) Update to default mockito version (defined in oak-parent)

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7678:

Labels: candidate_oak_1_8  (was: )

> Update to default mockito version (defined in oak-parent)
> -
>
> Key: OAK-7678
> URL: https://issues.apache.org/jira/browse/OAK-7678
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: authorization-cug, blob-cloud, blob-cloud-azure, 
> blob-plugins, core-spi, it, lucene, pojosr, query, run, search-mt, 
> segment-tar, segmentmk, solr, store-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>
> ...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7678) Update to default mockito version (defined in oak-parent)

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7678:

Summary: Update to default mockito version (defined in oak-parent)  (was: 
Update to latest mockito version)

> Update to default mockito version (defined in oak-parent)
> -
>
> Key: OAK-7678
> URL: https://issues.apache.org/jira/browse/OAK-7678
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: authorization-cug, blob-cloud, blob-cloud-azure, 
> blob-plugins, core-spi, it, lucene, pojosr, query, run, search-mt, 
> segment-tar, segmentmk, solr, store-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
>
> ...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7676) Build Jackrabbit Oak #1582 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7676:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1585|https://builds.apache.org/job/Jackrabbit%20Oak/1585/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1585/console]

> Build Jackrabbit Oak #1582 failed
> -
>
> Key: OAK-7676
> URL: https://issues.apache.org/jira/browse/OAK-7676
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1582 has failed.
> First failed run: [Jackrabbit Oak 
> #1582|https://builds.apache.org/job/Jackrabbit%20Oak/1582/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1582/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[JIRA]

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

Michael Dürig commented on OAK-7569:


{quote}My preferred option is keeping the current Jackrabbit API and getting 
the implementation right.
{quote}
+1

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7569:
---

bq. Anyway, any preference on the different options? Do you think 1 is ok or 
the „full“ static-less ValueFactoryImpl is feasible for an Oak code expert?

My preferred option is keeping the current Jackrabbit API and getting the 
implementation right.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7678) Update to latest mockito version

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7678:

Fix Version/s: 1.10

> Update to latest mockito version
> 
>
> Key: OAK-7678
> URL: https://issues.apache.org/jira/browse/OAK-7678
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: authorization-cug, blob-cloud, blob-cloud-azure, 
> blob-plugins, core-spi, it, lucene, pojosr, query, run, search-mt, 
> segment-tar, segmentmk, solr, store-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
>
> ...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7678) Update to latest mockito version

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7678:

Component/s: store-spi
 solr
 segmentmk
 segment-tar
 search-mt
 run
 query
 pojosr
 lucene
 it
 core-spi
 blob-plugins
 blob-cloud-azure
 blob-cloud
 authorization-cug

> Update to latest mockito version
> 
>
> Key: OAK-7678
> URL: https://issues.apache.org/jira/browse/OAK-7678
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: authorization-cug, blob-cloud, blob-cloud-azure, 
> blob-plugins, core-spi, it, lucene, pojosr, query, run, search-mt, 
> segment-tar, segmentmk, solr, store-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
>
> ...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7678) Update to latest mockito version

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7678:
---

 Summary: Update to latest mockito version
 Key: OAK-7678
 URL: https://issues.apache.org/jira/browse/OAK-7678
 Project: Jackrabbit Oak
  Issue Type: Task
Reporter: Julian Reschke
Assignee: Julian Reschke


...where no source code changes are needed...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7569:
---

I would not revert the changes right now.

The Jackrabbit API changes are already released and I don't see a benefit in 
reverting the changes immediately. We can decide to keep the Jackrabbit API 
dependency in Oak at version 2.17.4 if needed or even update to 2.17.5 and not 
implement the feature at this point.

The Oak API changes are in my view unrelated to the oak-jcr implementation 
issue discussed here and will likely not change anyway. The same applies to the 
changes to the lower layers already committed by Amit. I think it's fine to 
keep them and even create an Oak release.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7569:
-

I'm not that familiar with oak-jcr, so I really don't know how to proceed.

If there are currently doubts that we can proceed with the original plan, we 
may want to revert all changes that we currently have both in Jackrabbit trunk 
and Oak trunk in order to unblock releases of other things, and not to paint us 
into a corner.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on OAK-7569:


Ok, maybe then I might not know Oak‘s process for such API releases and how it 
relates to semantic versioning.

Anyway, any preference on the different options? Do you think 1 is ok or the 
„full“ static-less ValueFactoryImpl is feasible for an Oak code expert?

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7569:
-

Once again. "unstable" means "unstable". We are calling these releases 
"unstable" so that we *can* undo changes if needed.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 7:14 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].

Looking further, there are actually many static method usages of 
{{ValueFactoryImpl}} today, that all need to ensure a {{BlobAccessProvider}} is 
available, which is far from trivial.

[~mattvryan] and me think there are 2 solutions:
 # fix the static ValueFactoryImpl issue as much as possible (but ALL cases 
seem to be impossible to fix without a major Oak refactoring)
 # go back to the original API design (2a) or a slight variation thereof (2b) 
as a feasible compromise.

More details below.
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the direct binary access feature? One example is 
[AuthorizablePropertiesImpl|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/AuthorizablePropertiesImpl.java#L108].
 This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. 

[jira] [Commented] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on OAK-7569:


[~reschke] Yes, if by "here" you mean just talking about the API changes done 
for this feature in 2.17.5. Generally speaking, there cannot be breaking API 
changes (major version updates) in jackrabbit-api without disrupting the entire 
ecosystem. It's important to note the maven-bundle-plugin will not 
differentiate between the two - it will complain about both.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7569:
-

[~alexander.klimetschek] AFAIU there is no problem here - we can just undo the 
changes and release a unstable version. There are no compatibility guarantees 
here.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on OAK-7569:


Another approach for 2a) would be to keep 2.17.5 on maven release, but 
completely ignore it (mark it as broken), and for 2.17.6 just ignore following 
the semantic version changes (that are only based on stuff added in 2.17.5).

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 7:10 AM:


Another approach for 2a) would be to keep 2.17.5 on maven central, but 
completely ignore it (mark it as broken), and for 2.17.6 just ignore following 
the semantic version changes (that are only based on stuff added in 2.17.5).


was (Author: alexander.klimetschek):
Another approach for 2a) would be to keep 2.17.5 on maven release, but 
completely ignore it (mark it as broken), and for 2.17.6 just ignore following 
the semantic version changes (that are only based on stuff added in 2.17.5).

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 7:07 AM:


[~reschke] Please have a look at the details of 2a and 2b (just made some 
slight changes). Anything that forces {{org.apache.jackrabbit.api}} to have a 
breaking change and have it's package version go from 2.5.0 to 3.0.0 would be a 
no go as it would make all existing JCR client bundles using that package (and 
that will be most I reckon) incompatible without recompilation. I.e. just the 
upgrade to a newer Oak would break all these bundles.


was (Author: alexander.klimetschek):
[~reschke] Please have a look at the details of 2a and 2b (just made some 
slight changes). Anything that forces {{org.apache.jackrabbit.api}} to have a 
breaking change and have it's package version go from 2.5.0 to 3.0.0 would be a 
no go as it would make all existing JCR client bundles using that package (and 
that will be most I reckon) incompatible without recompilation.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on OAK-7569:


[~reschke] Please have a look at the details of 2a and 2b (just made some 
slight changes). Anything that forces {{org.apache.jackrabbit.api}} to have a 
breaking change and have it's package version go from 2.5.0 to 3.0.0 would be a 
no go as it would make all existing JCR client bundles using that package (and 
that will be most I reckon) incompatible without recompilation.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 7:03 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].

Looking further, there are actually many static method usages of 
{{ValueFactoryImpl}} today, that all need to ensure a {{BlobAccessProvider}} is 
available.

[~mattvryan] and me think there are 2 solutions:
 # fix the static ValueFactoryImpl issue as much as possible (but ALL cases 
seem to be impossible to fix without a major Oak refactoring)
 # go back to the original API design (2a) or a slight variation thereof (2b) 
as a feasible compromise.

More details below.
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the direct binary access feature? One example is 
[AuthorizablePropertiesImpl|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/AuthorizablePropertiesImpl.java#L108].
 This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but 

[jira] [Commented] (OAK-7569) Direct Binary Access

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7569:
-

We can't (IMHO) remove a release. That said, we *can* make breaking changes in 
Jackrabbit 2.17.* - there are no compatibility guarantees.

> Direct Binary Access
> 
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: api, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated 
> client to create or download blobs directly to/from the blob store, assuming 
> the authenticated user has appropriate permission to do so. The primary value 
> of this feature is that the I/O of transferring large binary files to or from 
> the blob store can be offloaded entirely from Oak and performed directly 
> between a client application and the blob store.
> This feature is described in more detail [on the Oak 
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575.  It adds the capability 
> to also upload directly to storage via preauthorized URLs in addition to 
> downloading directly from storage via preauthorized URLs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:56 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].

Looking further, there are actually many static method usages of 
{{ValueFactoryImpl}} today, that all need to ensure a {{BlobAccessProvider}} is 
available.

[~mattvryan] and me think there are 2 solutions:
 # fix the static ValueFactoryImpl issue as much as possible (but ALL cases 
seem to be impossible to fix without a major Oak refactoring)
 # go back to the original API design (2a) or a slight variation thereof (2b) 
as a feasible compromise.

More details below.
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the direct binary access feature? One example is 
[AuthorizablePropertiesImpl|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/AuthorizablePropertiesImpl.java#L108].
 This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but 

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:54 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].

Looking further, there are actually many static method usages of 
{{ValueFactoryImpl}} today, that all need to ensure a {{BlobAccessProvider}} is 
available.

[~mattvryan] and me think there are 2 solutions:
 # fix the static ValueFactoryImpl issue as much as possible (but ALL cases 
seem to be impossible to fix without a major Oak refactoring)
 # go back to the original API design (2a) or a slight variation thereof (2b) 
as a feasible compromise.

More details below.
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the direct binary access feature? One example is 
[AuthorizablePropertiesImpl|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/AuthorizablePropertiesImpl.java#L108].
 This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but 

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:53 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].

Looking further, there are actually many static method usages of 
{{ValueFactoryImpl}} today, that all need to ensure a {{BlobAccessProvider}} is 
available.

[~mattvryan] and me think there are 2 solutions:
 # fix the static ValueFactoryImpl issue as much as possible (but ALL cases 
seem to be impossible to fix without a major Oak refactoring)
 # go back to the original API design (2a) or a slight variation thereof (2b) 
as a feasible compromise.

More details below.
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the direct binary access feature? One example is 
{{AuthorizablePropertiesImpl}}. This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. 

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:52 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].

Looking further, there are actually many static method usages of 
{{ValueFactoryImpl}} today, that all need to ensure a {{BlobAccessProvider}} is 
available.

[~mattvryan] and me think there are 2 solutions:
# fix the static ValueFactoryImpl issue as much as possible (but ALL cases seem 
to be impossible to fix without a major Oak refactoring)
# go back to the original API design (2a) or a slight variation thereof (2b) as 
a feasible compromise.

More details below.

h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the change? One example is {{AuthorizablePropertiesImpl}}. 
This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. Furthermore we have to consider 

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:51 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].

[~mattvryan] and me think there are 2 solutions:
# fix the static ValueFactoryImpl issue as much as possible (but ALL cases seem 
to be impossible to fix without a major Oak refactoring)
# go back to the original API design (2a) or a slight variation thereof (2b) as 
a feasible compromise.

More details below.

h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the change? One example is {{AuthorizablePropertiesImpl}}. 
This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. Furthermore we have to consider future 
usage of these static methods (unless they become deprecated or removed).

FWIW, this is the reason in our original patch we did not extended the 

[jira] [Comment Edited] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on OAK-7677 at 8/6/18 6:50 AM:
-

trunk: [r1837475|http://svn.apache.org/r1837475]
1.8: [r1837477|http://svn.apache.org/r1837477]
1.6: [r1837481|http://svn.apache.org/r1837481]
1.4: [r1837482|http://svn.apache.org/r1837482]
1.2: [r1837483|http://svn.apache.org/r1837483]
1.0: [r1837484|http://svn.apache.org/r1837484]



was (Author: reschke):
trunk: [r1837475|http://svn.apache.org/r1837475]
1.8: [r1837477|http://svn.apache.org/r1837477]
1.6: [r1837481|http://svn.apache.org/r1837481]
1.4: [r1837482|http://svn.apache.org/r1837482]
1.2: [r1837483|http://svn.apache.org/r1837483]


> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10, 1.2.30, 1.0.43, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7677:

Fix Version/s: 1.0.43

> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10, 1.2.30, 1.0.43, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7677:

Labels:   (was: candidate_oak_1_0)

> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10, 1.2.30, 1.0.43, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:48 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This issue, that did not exist initially, and was tested, was introduced as a 
result of the refactorings during the review - which moved the API to a 
ValueFactory extension. At the same time the unit tests changed a bit, 
accidentally removing the important test case.

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the change? One example is {{AuthorizablePropertiesImpl}}. 
This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. Furthermore we have to consider future 
usage of these static methods (unless they become deprecated or removed).

FWIW, this is the reason in our original patch we did not extended the 
{{ValueFactory}} at all but used an extension interface 
({{BinaryAccessProvider}} on {{Session}}, as then access to the 
{{SessionContext}} and anything else is trivial. The idea of the 
{{ValueFactory}} as creator of values sounds good in theory, but the 
implementation in Oak using static methods creates values 

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:47 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence no one saw the issue earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This bug was introduced as a result of the refactorings during the review - 
which moved the API to a ValueFactory extension. At the same time the unit 
tests changed a bit (accidentally).

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the change? One example is {{AuthorizablePropertiesImpl}}. 
This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. Furthermore we have to consider future 
usage of these static methods (unless they become deprecated or removed).

FWIW, this is the reason in our original patch we did not extended the 
{{ValueFactory}} at all but used an extension interface 
({{BinaryAccessProvider}} on {{Session}}, as then access to the 
{{SessionContext}} and anything else is trivial. The idea of the 
{{ValueFactory}} as creator of values sounds good in theory, but the 
implementation in Oak using static methods creates values "out of thin air" 
with no access to other components.

Also note that this only 

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:46 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence we didn't see the issue earlier. This has been fixed in the 
latest changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This bug was introduced as a result of the refactorings during the review - 
which moved the API to a ValueFactory extension. At the same time the unit 
tests changed a bit (accidentally).

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the change? One example is {{AuthorizablePropertiesImpl}}. 
This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. Furthermore we have to consider future 
usage of these static methods (unless they become deprecated or removed).

FWIW, this is the reason in our original patch we did not extended the 
{{ValueFactory}} at all but used an extension interface 
({{BinaryAccessProvider}} on {{Session}}, as then access to the 
{{SessionContext}} and anything else is trivial. The idea of the 
{{ValueFactory}} as creator of values sounds good in theory, but the 
implementation in Oak using static methods creates values "out of thin air" 
with no access to other components.

Also note that this only 

[jira] [Comment Edited] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 6:46 AM:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary}} used for 
writing, hence we didn't see it earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This bug was introduced as a result of the refactorings during the review - 
which moved the API to a ValueFactory extension. At the same time the unit 
tests changed a bit (accidentally).

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the change? One example is {{AuthorizablePropertiesImpl}}. 
This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. Furthermore we have to consider future 
usage of these static methods (unless they become deprecated or removed).

FWIW, this is the reason in our original patch we did not extended the 
{{ValueFactory}} at all but used an extension interface 
({{BinaryAccessProvider}} on {{Session}}, as then access to the 
{{SessionContext}} and anything else is trivial. The idea of the 
{{ValueFactory}} as creator of values sounds good in theory, but the 
implementation in Oak using static methods creates values "out of thin air" 
with no access to other components.

Also note that this only applies 

[jira] [Commented] (OAK-7569) Direct Binary Access

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on OAK-7569:


h4. Problem

Unfortunately, we could not commit the final agreed change this week, because 
[~mattvryan] found a blocking issue: {{BinaryDownload.getURI()}} always returns 
null because the regular code path {{node.getProperty().getBinary()}} does not 
pass the {{BlobAccessProvider}} instance through to the {{ValueFactoryImpl}} 
because it uses a [static method of ValueFactoryImpl in 
PropertyImpl.getValue()|https://github.com/apache/jackrabbit-oak/blob/905c9bd0f716778a035a708bbdb8de634f464e66/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/PropertyImpl.java#L252-L253].
h4. Details

The unit tests so far had a shortcut where it reused the {{Binary used for 
writing, hence we didn't see it earlier. This has been fixed in the latest 
changes for the integration tests: 
[https://github.com/mattvryan/jackrabbit-oak/pull/12] (also includes a lot of 
improvements around the test framework itself).

This bug was introduced as a result of the refactorings during the review - 
which moved the API to a ValueFactory extension. At the same time the unit 
tests changed a bit (accidentally).

It is possible to fix this particular Value access case, since {{PropertyImpl}} 
already has access to the per-session {{ValueFactoryImpl}} instance, and it 
just needs to replace all the static usages left by leveraging 
{{getValueFactory()}}. Same for some other places in oak-jcr and oak-core that 
currently employ a mix of instance and static method access. [~mattvryan] did 
an attempt at this here: 
[https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]

Ideally, to ensure the {{blobAccessProvider}} reference in the 
{{ValueFactoryImpl}} is always set to the reference from the whiteboard that 
the {{SessionContext}} has, one would have to eliminate the static methods on 
{{ValueFactoryImpl}} and replace by instance methods. The class isn't doing 
proper encapsulation at this point, which is visible by the fact that 
{{NamePathMapper}}, an implementation detail the ValueFactoryImpl relies on, is 
actually all over the Oak code base.

*However, there are two static {{ValueFactoryImpl.createValue()}} methods 
retrieving a PropertyState and PropertyValue argument respectively (+ 
NamePathMapper) that are used in different places in oak, including 
oak-security-spi.* These are completely unrelated to the binary change. They 
don't have any immediate access to the {{SessionContext}} (which provides both 
the {{ValueFactoryImpl}} and {{BlobAcccessProvider}} instance). They all get a 
{{NamePathMapper}} passed in, which is essentially the same situation that a 
component reference must be available for the {{ValueFactoryImpl}} methods to 
do their work, but if you follow the call hierarchy it literally explodes. 
Meaning a lot of files all over Oak would have to be changed to actually pass 
through the {{ValueFactoryImpl}} instance instead of just {{NamePathMapper}}.

But even then, in many places it does not even get any access to the real 
{{NamePathMapper}} which {{SessionContext}} implements, but a 
{{NamePathMapper.DEFAULT}} is used (which apparently works for some of these 
cases?). It might be that some components were never designed to get access to 
the {{SessionContext}}, at least it seems it would be a massive refactoring to 
ensure that everywhere.
h4. Unsolved Binary cases

How does that affect the change? One example is {{AuthorizablePropertiesImpl}}. 
This corresponds to the code path of 
{{Authorizable.getProperty("foo").getValue().getBinary()}}, which would never 
be able to return anything from {{getURI()}}. Note that it will implement 
{{BinaryDownload}}, and the API contract is that {{getURI()}} shall return null 
if the feature is not available, but not if the client used the "wrong" way of 
retrieving a {{Binary}}.

Other cases are hard to reason about: it's unclear where exactly they could end 
up being used by a JCR client. We tried to analyze it but I am not sure one can 
make guarantees... and since the static methods aren't property-type specific, 
one cannot exclude binary properties. Furthermore we have to consider future 
usage of these static methods (unless they become deprecated or removed).

FWIW, this is the reason in our original patch we did not extended the 
{{ValueFactory}} at all but used an extension interface 
({{BinaryAccessProvider}} on {{Session}}, as then access to the 
{{SessionContext}} and anything else is trivial. The idea of the 
{{ValueFactory}} as creator of values sounds good in theory, but the 
implementation in Oak using static methods creates values "out of thin air" 
with no access to other components.

Also note that this only applies to downloads (BinaryDownload.getURI()). The 

[jira] [Commented] (OAK-7676) Build Jackrabbit Oak #1582 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7676:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1584|https://builds.apache.org/job/Jackrabbit%20Oak/1584/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1584/console]

> Build Jackrabbit Oak #1582 failed
> -
>
> Key: OAK-7676
> URL: https://issues.apache.org/jira/browse/OAK-7676
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1582 has failed.
> First failed run: [Jackrabbit Oak 
> #1582|https://builds.apache.org/job/Jackrabbit%20Oak/1582/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1582/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on OAK-7677 at 8/6/18 6:33 AM:
-

trunk: [r1837475|http://svn.apache.org/r1837475]
1.8: [r1837477|http://svn.apache.org/r1837477]
1.6: [r1837481|http://svn.apache.org/r1837481]
1.4: [r1837482|http://svn.apache.org/r1837482]
1.2: [r1837483|http://svn.apache.org/r1837483]



was (Author: reschke):
trunk: [r1837475|http://svn.apache.org/r1837475]
1.8: [r1837477|http://svn.apache.org/r1837477]
1.6: [r1837481|http://svn.apache.org/r1837481]
1.4: [r1837482|http://svn.apache.org/r1837482]


> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_0
> Fix For: 1.10, 1.2.30, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7677:

Fix Version/s: 1.2.30

> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_0
> Fix For: 1.10, 1.2.30, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7677:

Labels: candidate_oak_1_0  (was: candidate_oak_1_0 candidate_oak_1_2)

> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_0
> Fix For: 1.10, 1.2.30, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7677:

Labels: candidate_oak_1_0 candidate_oak_1_2  (was: candidate_oak_1_0 
candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6)

> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.10, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on OAK-7677 at 8/6/18 6:25 AM:
-

trunk: [r1837475|http://svn.apache.org/r1837475]
1.8: [r1837477|http://svn.apache.org/r1837477]
1.6: [r1837481|http://svn.apache.org/r1837481]
1.4: [r1837482|http://svn.apache.org/r1837482]



was (Author: reschke):
trunk: [r1837475|http://svn.apache.org/r1837475]
1.8: [r1837477|http://svn.apache.org/r1837477]


> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.10, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7677) Announcement mail template lacks line feeds in front of release notes

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7677:

Fix Version/s: 1.6.14
   1.4.23

> Announcement mail template lacks line feeds in front of release notes
> -
>
> Key: OAK-7677
> URL: https://issues.apache.org/jira/browse/OAK-7677
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.10, 1.4.23, 1.9.7, 1.6.14, 1.8.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)