[cdi-dev] TCK and spec question

Mark Struberg struberg at yahoo.de
Mon Dec 22 03:49:21 EST 2014


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.
>>> 
> 


More information about the cdi-dev mailing list