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