Hi Curtiss,
I tried out the scenario you described and it worked fine on my machine.
However I was using Sun's el-api and -impl.
After I changed to Apache's el-api and -impl I got the following error:
java.lang.IllegalArgumentException: Invalid property path. There is no
property attrs in entity at.jakobkorherr.myfaces.test.MyBean1
at
org.hibernate.validator.engine.ValidatorImpl.collectMetaConstraintsForPath(ValidatorImpl.java:684)
at
org.hibernate.validator.engine.ValidatorImpl.validateValue(ValidatorImpl.java:578)
at
org.hibernate.validator.engine.ValidatorImpl.validateValue(ValidatorImpl.java:146)
at javax.faces.validator.BeanValidator.validate(BeanValidator.java:164)
at
javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173)
at javax.faces.component.UIInput.validateValue(UIInput.java:378)
at javax.faces.component.UIInput.validate(UIInput.java:490)
at javax.faces.component.UIInput.processValidators(UIInput.java:213)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1132)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1132)
at javax.faces.component.UIForm.processValidators(UIForm.java:108)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1132)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1132)
at
javax.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1243)
at javax.faces.component.UIViewRoot.access$600(UIViewRoot.java:77)
at
javax.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1290)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1199)
at
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:675)
at
org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:35)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:146)
... 19 more
So this is definitely a bug on Tomcat's EL implementation. I suggest you
open a Tomcat-issue for this!
Regards,
Jakob
2010/5/24 Curtiss Howard <[email protected]>
> Our tester has been trying to get <f:validateBean> working with
> composite components and the "for" attribute, for example:
>
> <ex:ExampleComposite id="example1" managedBean="#{beanValidation}">
> <f:validateBean for="example1:input"/>
> </ex:ExampleComposite>
>
> So in reality the bean validation is happening for
> #{cc.attrs.beanValidation.value}. When we execute the bean validation
> code, we get an error complaining that our bean has no property named
> "attrs". Digging around, I see that eventually we're calling
> LocationValueExpressionUEL.getValueReference() to get the value
> reference which in turn calls ValueExpressionImpl.getValueReference().
> The ValueReference we get back correctly finds the managed bean, but
> the property is "attrs", when it should be "value". Digging around
> some more, it looks like the root of the problem is in the Apache EL
> code, in AstValue.getValueReference():
>
> return new ValueReference(t.base, this.jjtGetChild(1).getValue(ctx));
>
> I suspect getting the first child is the reason we get back "attrs".
> So, it seems to me that this code is broken in the case of composite
> components. Where should this problem be fixed? Should there be some
> hack to get the full expression string (how?) and chop off
> "cc.attrs.<bean name>." in _BeanValidatorUELUtils? Or can this be
> fixed in the Apache EL code?
>
> Thanks,
>
>
> Curtiss Howard
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
