[cdi-dev] TCK and spec question

[Jozef Hartinger]

Yes, we should explicitly define those other cases as non-portable if it 
has not been done yet.
On 12/22/2014 09:49 AM, Mark Struberg wrote:
> well, it's just the tip of the iceberg. It would be way easier to just define any 'modification' as non-portable. That would be much more precise and easier as well. And really covers al the edge cases as well.
>
> LieGrue,
> strub
>
>
>
>
>
>> On Monday, 22 December 2014, 9:42, Jozef Hartinger <jharting at redhat.com> wrote:
>> On 12/22/2014 09:33 AM, Mark Struberg wrote:
>>>   No you can NOT I fear.
>>>
>>>   How do you make sure that the AnnotatedType someone added doesn't get
>> changed later? We have no whatever control over it. If some programmer  like to
>> make it mutable, well then it is that way and we have no chance to detect that
>> :(
>>>   Imo the only thing we can do is to point programmers to the fact that this
>> is stupid -> non-portable behaviour.
>> Correct. This is stupid. But allowing setAnnotatedType() to be called
>> anytime does not help this at all.
>>
>> The fact that we throw the exception on setAnnotatedType() prevents a
>> class of bad things from happening. At the same time it does not prevent
>> the other one that you mentioned. The fact that we cannot prevent all of
>> them does not mean that we should not try to prevent those we can.
>>
>>>
>>>   LieGrue,
>>>   strub
>>>
>>>
>>>
>>>
>>>
>>>>   On Monday, 22 December 2014, 9:29, Jozef Hartinger
>> <jharting at redhat.com> wrote:
>>>>   On 12/21/2014 09:47 PM, Mark Struberg wrote:
>>>>>     Hi!
>>>>>
>>>>>     I just came across this little sentence in the spec
>>>>>
>>>>>
>>>>>
>>>>>     11.5.6 "If any ProcessAnnotatedType method is called outside
>> of the
>>>>   observer method invocation, an IllegalStateException is thrown."
>>>>>     I don't believe such a limitation helps much. What about
>> extensions who
>>>>   do a setAnnotatedType and change this instance in a later phase?
>>>>   Such as?
>>>>>       We have no whatever chance to prevent this anyway.
>>>>   We can prevent that by throwing the exception, rather than silently
>>>>   ignoring that the extension is doing something wrong.
>>>>
>>>>>     So why not just say that if a CDI System Event gets modified
>> outside of the
>>>>   method it gets injected into then non portable behaviour results.
>>>>>     LieGrue,
>>>>>     strub
>>>>>     _______________________________________________
>>>>>     cdi-dev mailing list
>>>>>    cdi-dev at lists.jboss.org
>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>     Note that for all code provided on this list, the provider
>> licenses the
>>>>   code under the Apache License, Version 2
>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided
>>>>   on this list, the provider waives all patent and other intellectual
>> property
>>>>   rights inherent in such information.
>>>>