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
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(a)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(a)redhat.com>
>> To: "Mark Struberg" <struberg(a)yahoo.de>, "John D.
Ament"
>> <john.d.ament(a)gmail.com>, "Tomas Remes"
<tremes(a)redhat.com>
>> Cc: cdi-dev(a)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(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.
>
>
> _______________________________________________
> 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.
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic