Re: [cdi-dev] TCK and spec question

On Monday, 22 December 2014, 9:56, Jozef Hartinger <jharting(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)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. >>>>