Re: What's the contract of QueryBuilder.impersonates(String name)?

[Michael Dürig]

Confirmed, this is principle name. At least this is what it was built 
for in Jackrabbit 2. The string passed is escaped vis 
org.apache.jackrabbit.oak.commons.QueryUtils#escapeForQuery




Michael

On 03.04.17 16:36, Angela Schreiber wrote:

Hi

I don't know how Michael intended it to work originally. Given the fact
that the impersonation setup is established and evaluated using principals
I would expect it to be a principal name, which in the default
implementation just can be any string value.

Kind regards
Angela

On 03/04/17 16:14, "Manfred Baedke"  wrote:


Hi all,

Can anyone clarify the contract of the method
org.apache.jackrabbit.api.security.user.QueryBuilder.impersonate(String
name)?
According to the JavaDoc, the parameter is the "name of an
authorizable". But the interface
org.apache.jackrabbit.api.security.user.Authorizable doesn't have a
name, just an id and a principal (which in turn has a name).
If a principal name is expected here (which seems to be the case
according to the implementations), then it needs to be specified if the
caller has to do any necessary escaping: if the user in question is e.g.
an LDAP user, it's principal name may contain backslash characters.

Best regards,
Manfred

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Manfred Baedke]

Hi Angela,

Thanks. So we would expect the caller to do the escaping, wouldn't we?

Best regards,
Manfred

On 4/3/2017 4:36 PM, Angela Schreiber wrote:

Hi

I don't know how Michael intended it to work originally. Given the fact
that the impersonation setup is established and evaluated using principals
I would expect it to be a principal name, which in the default
implementation just can be any string value.

Kind regards
Angela

On 03/04/17 16:14, "Manfred Baedke"  wrote:


Hi all,

Can anyone clarify the contract of the method
org.apache.jackrabbit.api.security.user.QueryBuilder.impersonate(String
name)?
According to the JavaDoc, the parameter is the "name of an
authorizable". But the interface
org.apache.jackrabbit.api.security.user.Authorizable doesn't have a
name, just an id and a principal (which in turn has a name).
If a principal name is expected here (which seems to be the case
according to the implementations), then it needs to be specified if the
caller has to do any necessary escaping: if the user in question is e.g.
an LDAP user, it's principal name may contain backslash characters.

Best regards,
Manfred

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Angela Schreiber]

Hi 

I don't know how Michael intended it to work originally. Given the fact
that the impersonation setup is established and evaluated using principals
I would expect it to be a principal name, which in the default
implementation just can be any string value.

Kind regards
Angela

On 03/04/17 16:14, "Manfred Baedke"  wrote:

>Hi all,
>
>Can anyone clarify the contract of the method
>org.apache.jackrabbit.api.security.user.QueryBuilder.impersonate(String
>name)?
>According to the JavaDoc, the parameter is the "name of an
>authorizable". But the interface
>org.apache.jackrabbit.api.security.user.Authorizable doesn't have a
>name, just an id and a principal (which in turn has a name).
>If a principal name is expected here (which seems to be the case
>according to the implementations), then it needs to be specified if the
>caller has to do any necessary escaping: if the user in question is e.g.
>an LDAP user, it's principal name may contain backslash characters.
>
>Best regards,
>Manfred

What's the contract of QueryBuilder.impersonates(String name)?

[Manfred Baedke]

Hi all,

Can anyone clarify the contract of the method 
org.apache.jackrabbit.api.security.user.QueryBuilder.impersonate(String 
name)?
According to the JavaDoc, the parameter is the "name of an 
authorizable". But the interface 
org.apache.jackrabbit.api.security.user.Authorizable doesn't have a 
name, just an id and a principal (which in turn has a name).
If a principal name is expected here (which seems to be the case 
according to the implementations), then it needs to be specified if the 
caller has to do any necessary escaping: if the user in question is e.g. 
an LDAP user, it's principal name may contain backslash characters.


Best regards,
Manfred

What's the contract of QueryBuilder.impersonates(String name)?

[Manfred Baedke]

Hi all,

Can anyone clarify the contract of the method 
org.apache.jackrabbit.api.security.user.QueryBuilder.impersonate(String 
name)?
According to the JavaDoc, the parameter is the "name of an 
authorizable". But the interface 
org.apache.jackrabbit.api.security.user.Authorizable doesn't have a 
name, just an id and a principal (which in turn has a name).
If a principal name is expected here (which seems to be the case 
according to the implementations), then it needs to be specified if the 
caller has to do any necessary escaping: if the user in question is e.g. 
an LDAP user, it's principal name may contain backslash characters.


Best regards,
Manfred

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.15

[Davide Giannella]

[X] +1 Release this package as Apache Jackrabbit Oak 1.4.15


D.

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.15

[Alex Parvulescu]

[X] +1 Release this package as Apache Jackrabbit Oak 1.4.15


alex

On Mon, Apr 3, 2017 at 1:28 PM, Davide Giannella  wrote:

>
> A candidate for the Jackrabbit Oak 1.4.15 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.15/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/
> jackrabbit-oak-1.4.15/
>
> The SHA1 checksum of the archive is
> 5130d4e0b212963bac6368e4949fab1dea1d76b9.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> $ sh check-release.sh oak 1.4.15
> 5130d4e0b212963bac6368e4949fab1dea1d76b9
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.4.15.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.4.15
> [ ] -1 Do not release this package because...
>
> Davide
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.15

[Julian Reschke]

On 2017-04-03 13:28, Davide Giannella wrote:

...


[X] +1 Release this package as Apache Jackrabbit Oak 1.4.15

Best regards, Julian

[VOTE] Release Apache Jackrabbit Oak 1.4.15

[Davide Giannella]

A candidate for the Jackrabbit Oak 1.4.15 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.15/

The release candidate is a zip archive of the sources in:

   
https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.15/

The SHA1 checksum of the archive is
5130d4e0b212963bac6368e4949fab1dea1d76b9.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

$ sh check-release.sh oak 1.4.15
5130d4e0b212963bac6368e4949fab1dea1d76b9

Please vote on releasing this package as Apache Jackrabbit Oak 1.4.15.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.4.15
[ ] -1 Do not release this package because...

Davide

Re: New JIRA component for observation

[Thomas Mueller]

Hi,

> I would prefer to stay aligned with Maven boundaries as much as possible 
> as this simplifies bug reporting for parties not deeply involved with 
> Oak very much.

Actually, I don't think that's a problem. I wouldn't expect such a person to 
specify any module (logical or maven).

>  Most of the apparent need to break out of that scheme is 
> to me rather a symptom of missing modularity rather than a cure.

It sounds like "modularity" for you means "Maven modularity". I don't agree 
this is the only "modularity" there is.

> If we introduce logical modules in Jira, I strongly suggest to come up with a 
> clear and concise definition for them: what exactly belongs to them, 
> what not?

Yes. And I would like to understand the reason on why we use modules (for 
reporting, easier to find issues,…?)

Regards,
Thomas

Re: Moving to Java 8

[Michael Dürig]

On 31.03.17 13:29, Julian Reschke wrote:

On 2017-02-15 12:17, Julian Reschke wrote:

Hi there,

I understand that we might not be able to move to Java 8 just yet, but I
felt it would be good to capture information related to this topic in
Jira (so that we can link other related tickets).

So feel free to provide feedback (and include more information) in

https://issues.apache.org/jira/browse/OAK-5664

Best regards, Julian


So far I didn't see anybody unhappy with a move to required Java 8 for
Oak 1.7 (unstable) and Oak 1.8 (once we get there in ~12 months). Thus,
I propose that we actually make the switch now.


+1 for 1.8.



Does anybody thing we need a vote?


No need for a vote IMO, (lazy) consensus here should be sufficient.

Michael



Best regards, Julian

Re: New JIRA component for observation

[Michael Dürig]

On 31.03.17 07:06, Chetan Mehrotra wrote:

On Thu, Mar 30, 2017 at 7:55 PM, Thomas Mueller  wrote:

Depending on that, we can use "Maven" module boundaries, or "Logical" module 
boundaries.


My preference is for "Logical" module boundaries and not be bounded by
the Maven module boundaries.



I would prefer to stay aligned with Maven boundaries as much as possible 
as this simplifies bug reporting for parties not deeply involved with 
Oak very much. Most of the apparent need to break out of that scheme is 
to me rather a symptom of missing modularity rather than a cure. If we 
introduce logical modules in Jira, I strongly suggest to come up with a 
clear and concise definition for them: what exactly belongs to them, 
what not? What are the criteria and how are they applied. Can modules 
overlap? Do they need to stay aligned with the boundaries of the Maven 
modules or can a logical module be part of multiple Maven modules?


Michael