Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@day.com designates
 207.126.148.88 as permitted sender)
Message-ID: <4B17F912.809@day.com>
Date: Thu, 03 Dec 2009 18:44:50 +0100
From: Angela Schreiber <anchela@day.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: Recommended way to take deal with JCR-1984
References: <1BD29549-07A4-4B17-B63B-FAC6B597EEAB@tfd.co.uk>
In-Reply-To: <1BD29549-07A4-4B17-B63B-FAC6B597EEAB@tfd.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>