Composite component required attribute throws exce

问题:

I've been playing around with JSF 2.0 composite components but I'm a bit confused as to what the require attribute in the composite:attribute tag is meant to do. The documentation says that the required attribute is true if the page author must supply a value for this attribute.

I've interpreted that as meaning that a value must be supplied for all composite:attributes that have required=true. I also assumed that an empty string is a valid value. And this is how it worked in Mojarra 2.0.2.

Using this simple managed bean:

@ManagedBean(name = "simpleMB")
@ViewScoped
public class SimpleManagedBean implements Serializable {

   private static final long serialVersionUID = -1;

   private String whatever;

   ... setter and getter
}

And the composite component:

<composite:interface>
    <composite:attribute name="value" required="true" />
</composite:interface>

<composite:implementation>
    <h:outputText value="Value: '#{cc.attrs.value}'" />    
</composite:implementation>

These tags worked in Mojarra 2.0.2:

<foo:bar value="" />
<foo:bar value="#{simpleMB.whatever}" />

However, when I upgraded to 2.0.3, only the first tag works. The second tag causes this error message:

/requiredAttribute.xhtml @20,42 <foo:bar> The following attribute(s) are 
required, but no values have been supplied for them: value.

It works fine when I set required to false.

Have I misinterpreted what the required attribute means? Can somebody clarify what behaviour I should expect?

Thanks.

回答1:

We have simular issues with required="true" in combination with @ViewScoped bean.

I our case the bean no longer behaves like a @ViewScoped bean (new constructor call every time).

Your problem might be that because the bean looses its scope the variabels are null again?

Either case the only awnser I can give you is to not use required="true" or use a @SessionScoped bean.

(Possibly this relates to the problem of Mojarra not being able to handle bindings to properties in @ViewScoped beans)

回答2:

I don't know if it is a bug, but it is the nature of el-expressions. Default expression type is String and empty string translated as null.

回答3:

This seems to have been this issue, which seems to have been closed a while ago, although I cannot seem to find in which version it was included.