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