Re: Issue with new validation scheme in HEAD

From: Adam Winer <>
Date: Thu, 17 May 2007 10:03:15 -0700

IMO, the original intent was always to support strict bean
names. Period should be reserved. For one reason, it could be
used later for creating hierarchies of beans. I also think it's
extremely confusing if developers type a managed bean name like
"" but:

DOES WORK #{requestScope['']}

I can't think of an EL syntax that will retrieve one
of these beans without knowing the scope its in.

I also remember a recent bug filed over here at Oracle
where a user had a managed bean named something like
"foo-bar". Of course, #{foo-bar} means "foo minus bar".

I think Shale should change.

-- Adam

Ryan Lubke wrote:
> David M. Lloyd wrote:
>> On Thu, 17 May 2007 08:32:16 -0700
>> Ryan Lubke <Ryan.Lubke_at_Sun.COM> wrote (quoting Craig):
>>> [...]
>>> The spec language doesn't say anything, but the JSF 1.1 DTD comment
>>> regarding <managed-bean-name> includes the comment 'It must be of
>>> type "Identifier"', which references back to a "type description"
>>> above claiming that the content must conform to the syntax of a valid
>>> Java identifier. I suspect that, when this DTD was translated into a
>>> schema, this requirement was taken literally.
>>> That creates an interesting backwards compatibility problem for
>>> Shale, but also an interesting spec question regarding backwards
>>> compatibility ... the RI for 1.2 is enforcing a requirement that the
>>> RI for 1.1 did not enforce, which could be argued is a breakage.
>>> But, in the mean time, I'm going to look at what the impact would be
>>> of correcting these names in Shale.
>>> We haven't released these changes yet, so this has no immediate
>>> impact, but it would be good to get a discussion going on this and
>>> figure out what should be done.
>>> For those of you on the EG, what do you think? Should the 1.2 schema
>>> be relaxed?
>> Not personally on the EG, but relaxing the schema has my vote, 110%.
>> No downside that I can see, and that behavior is, well, kind of
>> obnoxious. :-)
> EG or not, all feedback is welcome. The ultimate decision of course is
> with them.
>> - DML
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: