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

[Romain Manni-Bucau]

not forbidden but then you break other specs if they use javax as well
so not sure we can rely on it anyway


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-06 15:08 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
> 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