[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.

[Romain Manni-Bucau]

Agree a SHOULD instead of a MUST for - and only for - EL would be a
good compromise.


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


2015-01-14 21:58 GMT+01:00 Edward Burns <edward.burns at oracle.com>:
> I hope I can be allowed to inject myself into this conversation.  I can
> see a little emotional escalation creeping in here, so let's leave that
> between the keyboard and the chair.  Now, some comments below:
>
>>>>>> On Wed, 14 Jan 2015 12:12:57 +0000, Pete Muir <pmuir at redhat.com> said:
>
> PM> I agree with Martin. We *should* fix this situation in the long
> PM> term, which is what I proposed. However in the short term there is
> PM> no problem with not passing a particular test from the EL
> PM> spec. Additionally this is provably implementable as Weld implements
> PM> this, and many Java EE containers pass. As there are no other spec
> PM> defined beans javax, then we do not conflict with any other spec by
> PM> implementing it this way.
>
>>>>>> On Wed, 14 Jan 2015 15:52:17 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:
>
> MS> @Named("javax")
> MS> public class MyService {..}
>
>>>>>> On Wed, 14 Jan 2015 16:22:31 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:
>
> MS> is a perfectly valid CDI bean. Still it would be broken with Weld.
>
>>>>>> On Wed, 14 Jan 2015 16:19:31 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:
>
> MS> 6.7.5 just defines
>
> Spec> "The container provides a built-in bean with bean type
> Spec> Conversation, scope @RequestScoped, and qualifier @Default, named
> Spec> javax.enterprise.context.conversation."
>
> MS> It doesn't state that the bean must be available under
>
> MS> #{javax.enterprise.context.conversation} to the EL. This is simply
> MS> just implicated by the bean.name rules.
>
> MS> 3.) paragraph 2.6 Bean names:
>
> MS> It makes a bean visible to EL. BUT read the specified paragraph really carefula!
>
> Spec> "A bean may have a bean name. A bean with a name may be referred
> Spec> to by its name in Unified EL expressions. A valid bean name is a
> Spec> period-separated list of valid EL identifiers.
>
> MS> The important part is "list of _VALID_ EL identifiers"
>
> MS> What does this paragraph mean at all?
>
> MS> Does this mean that #{javax} is possible as is #{enterprise},
> MS> #{context} and #{conversation}? Because all those are valid EL
> MS> identifiers, wheras the combined string is NOT a valid EL
> MS> identifier.
>
> MS> If not and we go for your interpretation then we would also need to
> MS> support code like
>
> MS> @Named("oh.uh.some.other.weird.el.name"}
> MS> public class TotallyNonsenseService
>
> MS> You can turn this as you like. It simply makes no sense at all to
> MS> support it as EL name.
>
> MS> But there is a third option: This is just no valid EL identifier and
> MS> thus it is not exposed to EL but only to mechanism 1.) (@Inject
> MS> @Named) and 2.) (getBeans(String)).
>
> Along the line propopsed by Mark, the CDI spec section 6.7.5 could add
> some text to this effect,
>
>   For the purposes of exposing the conversation to EL, the conversation
>   is exposed via the EL name "javax_enterprise_context_Conversation".
>
> MS> And then break all applications which have a @Named("javax") public
> MS> class MyBean?  It's simply not an option imo. It breaks lots of
> MS> other specs and features. This is an XOR situation.
>
> I agree we can't do that.  Instead we could just add some text that
> states that there is no requirement for
> "javax.enterprise.context.conversation" to be exposed as an EL name.
>
> Would that work?
>
> Ed
>
> --
> | edward.burns at oracle.com | office: +1 407 458 0017
> | 36 days til DevNexus 2015
> | 46 days til JavaLand 2015
> | 56 days til CONFESS 2015