[cdi-dev] where is defined javax.enterprise.context.conversation.id?

[Martin Kouba]

Dne 6.1.2015 v 12:53 Romain Manni-Bucau napsal(a):
> Well it is quite explicit:
>
> 1.6 Operators [] and .
> The EL follows ECMAScript in unifying the treatment of the . and [] operators.
> expr-a.identifier-b is equivalent to expr-a[“identifier-b”]; that is, the
> identifier identifier-b is used to construct a literal whose value is
> the identifier,
> and then the [] operator is used with that value.
>
> so javax.enterprise.context.conversation.id =
> javax["enterprise"]["context"]["conversation"]["id"].
>
> If then you follow the EL resolution agorithm there is no way which
> can match our name case -

It's possible although not very convenient. A custom ELResolver can 
handle these "virtual" properties. Weld builds a special namespace 
hierarchy, so that for instance javax["enterprise"] returns a Namespace 
object which has a virtual property "context" of type Namespace, etc. 
Again it's not nice and certainly not efficient. But it's not forbidden 
imho.

and EL is only inspired from ECMA and doesnt
> follow all its rules.
>
> The best would be to add a "cdi" object (whatever name it is while it
> is compliant) and to allow:
>
> ${cdi['javax.enterprise.context.conversation']} syntax, exactly like
> requestScope can be used to get javax.servlet.* properties.

Yep, this might be a better approach.

>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-06 12:46 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>>
>> Well I am not sure. Reading EL spec and ECMA script I can't see any wording which will imply a must to escape or quote the variable in this case. I think the current usage is not forbidden anywhere. I tried to escape or quote the part of variable but it didn't work. The result was considered as String instance or I got ParserException.
>>
>> Tom
>>
>> ----- Original Message -----
>> From: "Jozef Hartinger" <jharting at redhat.com>
>> To: "Mark Struberg" <struberg at yahoo.de>, "John D. Ament" <john.d.ament at gmail.com>, "Tomas Remes" <tremes at redhat.com>
>> Cc: cdi-dev at lists.jboss.org
>> Sent: Monday, January 5, 2015 4:19:16 PM
>> Subject: Re: [cdi-dev] where is defined javax.enterprise.context.conversation.id?
>>
>>
>> On 01/05/2015 10:09 AM, Mark Struberg wrote:
>>>>> The spec also only says that the BEAN must have this very name and not that
>>>>> the bean must be accessible by EL.
>>>> Given what the name is for in CDI this can be implied.
>>>
>>> well, but it's not up to the CDI impl to do this correctly.
>> No, my point was that if a bean is given a name it implies that this
>> bean should be accessible via EL.
>>>
>>>
>>>>> If we would really require this and the EL specification doesn't
>>>>> support it, then the CDI spec would contradict the EL spec, right?
>>>> No, it would mean that the name should be placed within quotes when
>>>> accessing the conversation bean from EL.
>>>
>>> The question is whether it really is defined in the EL spec that way. And further if the EL TCK does test this or if this is non-portable. The TCK test doesn't use escaping for what I saw. So this test is not ok.
>> Right, the TCK test should be fixed to escape the name properly.
>>
>>>
>>>
>>> Why didn't we simply use underscores instead of dots? :)
>>>
>>>
>>> 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.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic