Re: [weld-dev] Clarification question on CDI specification section 2.2.1
by Matej Novotny
----- Original Message -----
> From: "Laird Nelson" <ljnelson(a)gmail.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Sent: Thursday, February 27, 2020 5:35:53 PM
> Subject: Re: [weld-dev] Clarification question on CDI specification section 2.2.1
>
> On Thu, Feb 27, 2020 at 1:34 AM Matej Novotny <manovotn(a)redhat.com> wrote:
>
> > the two bullet points IMO do not have an overlap, e.g. your bean can be an
> > array type but there is no (…
[View More]un)boxing there, or it can be a primitive type
> > in which case there is (un)boxing.
> >
>
> OK. Clearly this is the behavior, so it's just the language that is
> imprecise, i.e. "identical" is used in at least two senses, maybe three,
> not just one.
>
> Also: "Two array types are considered identical only if the element type is
> identical." Why does this sentence exist? What is it trying to tell me?
Over the years I have seen little usage of arrays as beans, this might well be underspecified area.
However, due to backward compatibility requirements, we wouldn't be able to make huge changes to existing behavior.
In other words, looking into what Weld does in these cases is probably a good starting point for any spec clarifications.
>
> And is a GenericArrayType an "array type"?
That's a good question, frankly I don't know.
> Should ArrayList[] be
> assignable to ArrayList<Integer>[]?
This sounds like something that should not work as the elements of these arrays can wildly differ.
>
> If you think it's unclear, feel free to propose better wording in CDI.
> > They're using GH issues now - https://github.com/eclipse-ee4j/cdi
>
>
> Thanks.
>
> Laird
>
[View Less]
5 years
Clarification question on CDI specification section 2.2.1
by Laird Nelson
I found a need to look at section 2.2.1 of the specification (
https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#legal_bean_types
).
It says (in part, and I quote):
- A bean type may be an array type. Two array types are considered
identical only if the element type is identical.
- A bean type may be a primitive type. Primitive types are considered to
be identical to their corresponding wrapper types in java.lang.
I want to ask a question about the word "identical" in …
[View More]the bullet points
above. I'll refer to the bullet points above as #1 and #2 respectively.
Obviously (for example) Object.class is identical to Object.class. This
cannot be in doubt.
Next, let's look at #2. #2 effectively says that for the purposes of CDI,
int.class is "identical to" Integer.class. This is true in CDI even
though int.class
!= Integer.class and int.class.equals(Integer.class). I understand this
fully; this is effectively boxing and unboxing conversions as defined by
the JLS (
https://docs.oracle.com/javase/specs/jls/se13/html/jls-5.html#jls-5.1.7).
Now consider int[].class and Integer[].class.
In Java, this doesn't compile (obviously):
final Integer[] integers = new int[0];
And this doesn't compile either (equally obviously):
final int[] ints = new Integer[0];
But in #1, the second sentence (together with section 5.2.1 where typesafe
resolution is discussed) seems to indicate that *for the purposes of CDI* a
target type of Integer[].class should be able to conceptually accept a bean
type of int[].class (and vice versa).
This would seem to be the case because Integer[].class.getComponentType()
is Integer.class, and int[].class.getComponentType() is int.class, and
(according to #2) Integer.class is "identical to" int.class.
Was this the intention? Was it intended that, for example, a producer
method that returns int[] should be able to have its return value converted
by the container so that it "fits in" an injection point of type
Integer[].class? Or was this imprecise use of language, where "identical"
in #2 doesn't apply to #1?
Thanks,
Best,
Laird
[View Less]
5 years
Follow up to WELD-2611
by Benjamin Confino
Hello
I heard back from my excellent L2 support colleague who has tested the
weld fix and he says that it works perfect when you append something like
"?cid=100000" to the url but not if you append "?cid=" I debugged into the
code and I believe that what is happening is that:
AbstractConversationContext.initilize treats a null or an isEmpty() cid as
as a trigger to enter the else block and call
associateRequestWithNewConversation()
However LazyHttpConversationContextImpl.…
[View More]checkContextInitialized() only
calls fireInitEvent() for a null cid or in the catch block for a
ConversationNotActiveException.
The two methods have differing understandings of what's triggers a new
conversation, so the "?cid=" case falls through the gap. I think this can
be fixed by adding an "|| cid.isEmpty()" to
LazyHttpConversationContextImpl.checkContextInitialized() above the
non-catch block call to fireInitEvent(), if you agree I can spin up a
couple of pull requests.
Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[View Less]
5 years, 1 month
Question about conversations scope initilization obeserver
by Benjamin Confino
Hello
I have a customer who's sent me a sample application, I have attached the
source to it below.
When the customer visits index.xhtml they see the following output:
Conversation initialized.
Conversation begun. cid:1, timeout:3600000
Conversation destroyed. cid:1
However when they append "?cdi=" or a non-existnant identifier like
"?cdi=10000" to the url they do not see "Conversation initialized."
The CDI spec says that: If the propagated conversation cannot be restored,
the …
[View More]container must associate the request with a new transient conversation
and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
I'm wondering if this should apply here? Or would it only apply if the cid
pointed to an existing conversation that could not be restored? And is
there anything in the spec that covers this specific situation?
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[View Less]
5 years, 1 month