Re: Recommended way to take deal with JCR-1984

[Ian Boston <ie...@tfd.co.uk>]

Felix,
yes thank you,
got the update through which did as you say fix about 4 of the tests  
in Sling (and found the sling jira now).
BTW I think the other problems I am having with {internal}privileges  
not being defined are of my own making, although I did notice the  
launch-pad tests are using 2.0.4-incubator of JCR Base rather than  
2.0.5-SNAPSHOT which is in the code base so upgrading the JR API to  
1.6 in the current trunk wont flow through. (not that it fixes any of  
the remaining tests)
Ian

(ccd dev@sling)

On 3 Dec 2009, at 20:46, Felix Meschberger wrote:

> Hi Ian
>
> In fact I rewrote a Sling integration test just this morning exactly
> doing such property setting for verification purposes (the test used  
> to
> check the rep:principalName property which is not available as such  
> any
> longer).
>
> Regards
> Felix
>
> Ian Boston schrieb:
>> Angela,
>> Fantastic,
>> I misread the patch forgetting that * might be allowed.
>> Thank you.
>> Ian
>>
>> On 3 Dec 2009, at 17:44, Angela Schreiber wrote:
>>
>>> hi ian
>>>
>>> JCR-1984 addressed a problem that protected properties defined
>>> by the user/group node types were exposed by the #getPropertyNames
>>> and #getProperty methods, although they could not be modified
>>> by the corresponding set/remove methods.
>>>
>>> this issue should not affect additional, application specific
>>> properties that were or will be stored with a user/group.
>>> the nodetype still allows for
>>>
>>> - * (UNDEFINED)
>>> - * (UNDEFINED) multiple
>>>
>>> and those props should be exposed by the mentioned methods.
>>> i'm not aware of any change that would have broken this.
>>>
>>> angela
>>>
>>>
>>>
>>> Ian Boston wrote:
>>>> Hi,
>>>> IIUC [1], post 1.6 blocks an authorizable node from holding any
>>>> properties, other than those listed in the schema.
>>>> How do I add and retrieve a well defined set of properties for the
>>>> node as was possible in JR15 ?
>>>> We have an application that stores extra group and user metadata on
>>>> the authorizable node and I really don't want to have to rewrite  
>>>> it.
>>>> Thanks
>>>> Ian
>>>> 1 https://issues.apache.org/jira/browse/JCR-1984
>>>
>>
>>

Re: Recommended way to take deal with JCR-1984

[Felix Meschberger <fm...@gmail.com>]

Hi,

Ian Boston schrieb:
> Felix,
> yes thank you,
> got the update through which did as you say fix about 4 of the tests in
> Sling (and found the sling jira now).
> BTW I think the other problems I am having with {internal}privileges not
> being defined are of my own making,

ok.

> although I did notice the launch-pad
> tests are using 2.0.4-incubator of JCR Base rather than 2.0.5-SNAPSHOT
> which is in the code base so upgrading the JR API to 1.6 in the current
> trunk wont flow through. (not that it fixes any of the remaining tests)

Yes, but this doesn't matter because the jcr/base module just provides
AccessControlUtil class, which is pure API calling. This doesn't matter
whether it is 1.5 or 1.6.

In fact updating the access manager dependency to the SNAPSHOT fixed the
tests (after fixing the access manager bundle).

Regards
Felix

... end of crossposting ;-)

> Ian
> 
> (ccd dev@sling)
> 
> On 3 Dec 2009, at 20:46, Felix Meschberger wrote:
> 
>> Hi Ian
>>
>> In fact I rewrote a Sling integration test just this morning exactly
>> doing such property setting for verification purposes (the test used to
>> check the rep:principalName property which is not available as such any
>> longer).
>>
>> Regards
>> Felix
>>
>> Ian Boston schrieb:
>>> Angela,
>>> Fantastic,
>>> I misread the patch forgetting that * might be allowed.
>>> Thank you.
>>> Ian
>>>
>>> On 3 Dec 2009, at 17:44, Angela Schreiber wrote:
>>>
>>>> hi ian
>>>>
>>>> JCR-1984 addressed a problem that protected properties defined
>>>> by the user/group node types were exposed by the #getPropertyNames
>>>> and #getProperty methods, although they could not be modified
>>>> by the corresponding set/remove methods.
>>>>
>>>> this issue should not affect additional, application specific
>>>> properties that were or will be stored with a user/group.
>>>> the nodetype still allows for
>>>>
>>>> - * (UNDEFINED)
>>>> - * (UNDEFINED) multiple
>>>>
>>>> and those props should be exposed by the mentioned methods.
>>>> i'm not aware of any change that would have broken this.
>>>>
>>>> angela
>>>>
>>>>
>>>>
>>>> Ian Boston wrote:
>>>>> Hi,
>>>>> IIUC [1], post 1.6 blocks an authorizable node from holding any
>>>>> properties, other than those listed in the schema.
>>>>> How do I add and retrieve a well defined set of properties for the
>>>>> node as was possible in JR15 ?
>>>>> We have an application that stores extra group and user metadata on
>>>>> the authorizable node and I really don't want to have to rewrite it.
>>>>> Thanks
>>>>> Ian
>>>>> 1 https://issues.apache.org/jira/browse/JCR-1984
>>>>
>>>
>>>
> 
> 

Re: Recommended way to take deal with JCR-1984

[Felix Meschberger <fm...@gmail.com>]

Hi,

Ian Boston schrieb:
> Felix,
> yes thank you,
> got the update through which did as you say fix about 4 of the tests in
> Sling (and found the sling jira now).
> BTW I think the other problems I am having with {internal}privileges not
> being defined are of my own making,

ok.

> although I did notice the launch-pad
> tests are using 2.0.4-incubator of JCR Base rather than 2.0.5-SNAPSHOT
> which is in the code base so upgrading the JR API to 1.6 in the current
> trunk wont flow through. (not that it fixes any of the remaining tests)

Yes, but this doesn't matter because the jcr/base module just provides
AccessControlUtil class, which is pure API calling. This doesn't matter
whether it is 1.5 or 1.6.

In fact updating the access manager dependency to the SNAPSHOT fixed the
tests (after fixing the access manager bundle).

Regards
Felix

... end of crossposting ;-)

> Ian
> 
> (ccd dev@sling)
> 
> On 3 Dec 2009, at 20:46, Felix Meschberger wrote:
> 
>> Hi Ian
>>
>> In fact I rewrote a Sling integration test just this morning exactly
>> doing such property setting for verification purposes (the test used to
>> check the rep:principalName property which is not available as such any
>> longer).
>>
>> Regards
>> Felix
>>
>> Ian Boston schrieb:
>>> Angela,
>>> Fantastic,
>>> I misread the patch forgetting that * might be allowed.
>>> Thank you.
>>> Ian
>>>
>>> On 3 Dec 2009, at 17:44, Angela Schreiber wrote:
>>>
>>>> hi ian
>>>>
>>>> JCR-1984 addressed a problem that protected properties defined
>>>> by the user/group node types were exposed by the #getPropertyNames
>>>> and #getProperty methods, although they could not be modified
>>>> by the corresponding set/remove methods.
>>>>
>>>> this issue should not affect additional, application specific
>>>> properties that were or will be stored with a user/group.
>>>> the nodetype still allows for
>>>>
>>>> - * (UNDEFINED)
>>>> - * (UNDEFINED) multiple
>>>>
>>>> and those props should be exposed by the mentioned methods.
>>>> i'm not aware of any change that would have broken this.
>>>>
>>>> angela
>>>>
>>>>
>>>>
>>>> Ian Boston wrote:
>>>>> Hi,
>>>>> IIUC [1], post 1.6 blocks an authorizable node from holding any
>>>>> properties, other than those listed in the schema.
>>>>> How do I add and retrieve a well defined set of properties for the
>>>>> node as was possible in JR15 ?
>>>>> We have an application that stores extra group and user metadata on
>>>>> the authorizable node and I really don't want to have to rewrite it.
>>>>> Thanks
>>>>> Ian
>>>>> 1 https://issues.apache.org/jira/browse/JCR-1984
>>>>
>>>
>>>
> 
>