Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.219.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50996E54.6090700@oracle.com>
References: <5092EF5B.3040606@oracle.com>
	<50938A9D.6020208@apache.org>
	<5093D166.1030503@oracle.com>
	<CAFYk8NmjyLP9X9a-UPEzp2RCh7Zd8h+N0Fn6cePnceo7YqMgEA@mail.gmail.com>
	<50996E54.6090700@oracle.com>
Date: Wed, 7 Nov 2012 09:52:20 +0100
Message-ID: 
 <CAFYk8N=pmbpVTht=oJHAEowi5x+dTtOFFwCJPkJm=8oCywxpMA@mail.gmail.com>
Subject: Re: Node property type constraints violated when setting strings
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi jessi,

On Tue, Nov 6, 2012 at 9:08 PM, Jessi Abrahams
<jessi.abrahams@oracle.com> wrote:
> Hi Stefan,
>
> It looks like you were right that I was extending a node type with residu=
al
> property definitions - I oversimplified the example I gave so it was not
> apparent. I've fixed the problematic inheritance and the repository is
> validating as expected. Thanks for your help.

good to hear and thanks for the feedback.

cheers
stefan

>
> Jessi
>
>
> On 11/02/2012 10:42 AM, Stefan Guggisberg wrote:
>>
>> On Fri, Nov 2, 2012 at 2:57 PM, Jessi Abrahams
>> <jessi.abrahams@oracle.com> wrote:
>>>
>>> Hi Michael,
>>>
>>> Thanks for your response. Based on that spec I would expect that if I
>>> tried
>>> to assign a value of "abc" then the property would end up being set to
>>> false
>>> (based on how Java converts strings to booleans). However what I am
>>> seeing
>>> is the property being assigned a string value of "abc".
>>
>> that would be a major bug. however, i suppose that your custom node type
>> extends a node type containing residual property definitions (such as e.=
g.
>> nt;unstructured).
>>
>> you can verify the declaring node type by running something like
>>
>> Property prop =3D node.setProperty("someBooleanProperty", "abc");
>> System.out.println(PropertyType.nameFromValue(prop.getType()));
>> PropertyDefinition def =3D prop.getDefinition();
>> System.out.println(def.getDeclaringNodeType().getName());
>> System.out.println(PropertyType.nameFromValue(def.getRequiredType()));
>>
>> cheers
>> stefan
>>
>>> Thanks
>>> Jessi
>>>
>>>
>>> On 11/02/2012 04:55 AM, Michael D=FCrig wrote:
>>>>
>>>>
>>>> Jessi,
>>>>
>>>> The repository will try to convert the string to a boolean. See 3.6.4
>>>> Property Type Conversion in JSR 283.
>>>>
>>>> Michael
>>>>
>>>> On 1.11.12 21:53, Jessi Abrahams wrote:
>>>>>
>>>>> Hi,
>>>>> I'm new to this list so I apologize if this question has been asked (=
I
>>>>> tried searching the archives) or if this is not the right place to as=
k.
>>>>>
>>>>> I have a custom node type with a definition like this:
>>>>>
>>>>> [foo:bar] > mix:lastModified, mix:created, nt:base
>>>>>     - someBooleanProperty (BOOLEAN)
>>>>>
>>>>> When I create a node of this type and use any of the setProperty
>>>>> methods
>>>>> on Node, the repository allows me to set string values (such as "abc"=
)
>>>>> for someBooleanProperty even though as far as I understand from the
>>>>> type
>>>>> definition, only booleans should be allowed. The repository throws a
>>>>> ConstraintViolationException (as I would expect) if I try to to set
>>>>> someBooleanProperty to any other incorrect (non-boolean) type - but n=
ot
>>>>> strings. It seems like properties can always be set to a string,
>>>>> whether
>>>>> or not it's allowed by the node type definition. Is this expected? It
>>>>> doesn't seem in line with the spec.
>>>>>
>>>>> Thanks
>>>>> Jessi
>>>>>
>>>>>
>>>>>
>>>
>
>