[cdi-dev] TCK and spec question

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-12-22 9:49 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
> 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.
>>>>
>>
> _______________________________________________
> 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.