[cdi-dev] TCK and spec question

Antoine Sabot-Durand antoine at sabot-durand.net
Tue Dec 23 03:17:04 EST 2014


Mark,

Could you add a ticket for that. 

Antoine Sabot-Durand

> Le 22 déc. 2014 à 09:59, Mark Struberg <struberg at yahoo.de> a écrit :
> 
> While we are at it: This is actually true for ALL System Events, right?
> So we should not define it in PAT but somewhere more general imo.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
>>> On Monday, 22 December 2014, 9:56, Jozef Hartinger <jharting at redhat.com> wrote:
>>> 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.
> _______________________________________________
> 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.



More information about the cdi-dev mailing list