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

[Edward Burns]

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