|
|
Re: NPE in EcoreSchemaBuilder transformDefaultValue [message #877303 is a reply to message #877242] |
Sat, 26 May 2012 11:36 |
Alain Picard Messages: 266 Registered: July 2009 |
Senior Member |
|
|
On 5/26/2012 3:19 AM, Ed Merks wrote:
> Alain,
>
> Comments below.
>
> On 26/05/2012 2:42 AM, Alain Picard wrote:
>> Hi,
>>
>> I am getting an NPE in EcoreSchemaBuilder.transformDefaultValue.
>>
>> In debugging mode I traced the issue to a structural feature of type
>> EBoolean with a default value of "true".
>>
>> The line:
>> XSDSimpleTypeDefinition primitiveTypeDefinition =
>> xsdSimpleTypeDefinition.getPrimitiveTypeDefinition();
>>
>> returns null for primitiveTypeDefinition for my
>> xsdSimpleTypeDefinition representing my Boolean EDataType.
> It sounds like this.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=377376
>
> The fix for that was committed a few weeks ago. You should be able to
> find it in the Juno RC1 repo.
I'll test that and let you know but it is quite possibly the same thing.
>>
>> I have looked a bit at the code but I'm quite clueless as to where to
>> start investigating here.
>>
>> I did notice that when this XSDSimpleTypeDefinition is being built in
>> buildAttributeUse, that the namespace is reporting null.
>>
>> Can anyone point me in some direction to investigate this issue. This
>> is my only default value so I'll take it out for now at least to
>> generate my xsd, but this is weird and a pain.
>>
>> BTW, I have had other cases of NPE in the same method that are
>> normally caused by empty string default value literal that can appear
>> in the ecore model if you inadvertently edit the default field and you
>> don't remove the attribute manually.
> If you find there are other problems after the above fix, please report
> them as soon as possible so I can make any other fixes in time for Juno!
The other issue is repeatable and more due to the fact that the EMF
editor, when you remove an existing value for a field will set the field
as an empty string instead of un-setting the field, thus resulting in a
default of empty which is not null.
>>
>> Cheers,
>> Alain
|
|
|
Re: NPE in EcoreSchemaBuilder transformDefaultValue [message #877364 is a reply to message #877303] |
Sat, 26 May 2012 14:57 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Alain,
The general problem of how to distinguish null from the empty string for
text fields or cell editors is annoying and pervasive. There is a
little button in the properties view to reset the value and that will
set it to null...
On 26/05/2012 1:36 PM, Alain Picard wrote:
> On 5/26/2012 3:19 AM, Ed Merks wrote:
>> Alain,
>>
>> Comments below.
>>
>> On 26/05/2012 2:42 AM, Alain Picard wrote:
>>> Hi,
>>>
>>> I am getting an NPE in EcoreSchemaBuilder.transformDefaultValue.
>>>
>>> In debugging mode I traced the issue to a structural feature of type
>>> EBoolean with a default value of "true".
>>>
>>> The line:
>>> XSDSimpleTypeDefinition primitiveTypeDefinition =
>>> xsdSimpleTypeDefinition.getPrimitiveTypeDefinition();
>>>
>>> returns null for primitiveTypeDefinition for my
>>> xsdSimpleTypeDefinition representing my Boolean EDataType.
>> It sounds like this.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=377376
>>
>> The fix for that was committed a few weeks ago. You should be able to
>> find it in the Juno RC1 repo.
> I'll test that and let you know but it is quite possibly the same thing.
>
>>>
>>> I have looked a bit at the code but I'm quite clueless as to where to
>>> start investigating here.
>>>
>>> I did notice that when this XSDSimpleTypeDefinition is being built in
>>> buildAttributeUse, that the namespace is reporting null.
>>>
>>> Can anyone point me in some direction to investigate this issue. This
>>> is my only default value so I'll take it out for now at least to
>>> generate my xsd, but this is weird and a pain.
>>>
>>> BTW, I have had other cases of NPE in the same method that are
>>> normally caused by empty string default value literal that can appear
>>> in the ecore model if you inadvertently edit the default field and you
>>> don't remove the attribute manually.
>> If you find there are other problems after the above fix, please report
>> them as soon as possible so I can make any other fixes in time for Juno!
> The other issue is repeatable and more due to the fact that the EMF
> editor, when you remove an existing value for a field will set the
> field as an empty string instead of un-setting the field, thus
> resulting in a default of empty which is not null.
>>>
>>> Cheers,
>>> Alain
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.02720 seconds