Hmm. I know myfaces had a bug where resource-bundles are not available
during the postback phase.
I wonder if that ever got fixed. If not, that might be the cause.
Usually resource-bundles are not needed during postback; generation of
text output is done during rendering. Except that *validation messages*
are of course resolved during the postback phase.
I suggest you search the myfaces JIRA system to see if you can find an
existing issue related to resource-bundles and postback. If so, then
that's the problem. As a workaround, you might try writing a
PhaseListener that always stores your resource-bundle into the current
request scope; that should be about 10 lines of code.
Anyway even using a simple literal for the label is at least better than
what you had before, right?
Regards,
Simon
j.palleschitz schrieb:
> thanks simon,
>
> the label-parameter looked like a solution.
> but it cannot resolve my resource-bundles.
>
> if i set label="#{label.username}" the message start with ": ..."
> when label="Username" it looks fine.
>
> so it´s not the solution i´ve looked for.
>
> i can´t believe that such a behavior is wanted from myfaces.
>
>
>
> Simon Kitching wrote:
>
>> While testing something else, I took a moment to check how Sun's Mojarra
>> handles required-messages. It also inserts the clientId (ie *with* the
>> form/subview prefix). Therefore myfaces 1.2.x and mojarra currently work
>> the same. I think it unlikely that MyFaces would accept a patch to
>> change its default behaviour to something different from Mojarra, although
>> (a) you could try; the decision is not mine to make, and
>> (b) you could create and offer a patch to make the behaviour configurable
>>
>> Re the "label" attribute I mentioned below: it looks like JSF also added
>> this optional attribute to customise the {0} parameter, eg
>> <h:input id="someProgrammerId" label="someUserLabel" required="true"../>
>> will generate whatever generic "required" message is configured, but
>> with {0} set to "someUserLabel". This feature still requires setting
>> this on each component though.
>>
>> Regards,
>> Simon
>>
>>
>
>
--
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)
