Re: JSF 2.0 - Bean Validation, Unified EL and other specs

From: Ryan Lubke <Ryan.Lubke_at_Sun.COM>
Date: Mon, 26 Oct 2009 21:56:19 -0700

On 10/25/09 10:57 AM, Jan-Kees van Andel wrote:
> Hey (CC MyFaces Dev),
> For MyFaces, I have implemented the first version of Bean Validation
> support. But my implementation had a TCK issue, because I had some
> non-specified public fields. These fields indicated the runtime
> availability of some libraries.
> See: for the issue.
> To fix it, I've moved the public fields to a separate, package-private
> class (still in the API), to hide them from end users and fix TCK
> issues.
> But the problem with this solution is that the fields are used in more
> than one package (currently "validate" and "component". Probably more
> to come), giving me only one option: Code duplication.
> I personally hate code duplication, which leads me to the question: Is
> it a good idea to put an API in the spec which contains the
> information I'm providing in my current class?
> Initially I wrote this message because I hate code duplication, but
> there might be another benefit, since 3th party libraries may also
> want to check the existence of certain libraries. Especially Bean
> Validation and Web Beans may have impact on framework/component
> authors. I think some API like this is quite important, because JSF
> (since 2.0) doesn't live on its own anymore, but interacts with other
> libraries as well.
> My implementation
> (
> currently works for MyFaces, but the official API may need to be a bit
> more reusable/extensible.
> I was thinking of something simple:
> public interface FacesEnvironment /* This name probably sucks */ {
> public boolean isBeanValidationAvailable();
> public boolean isUnifiedELAvailable();
> // ...
> }
> An interface might be overkill, but the EG may work out the details. ;-)
Specifics such as interfaces aside, this seems like a useful concept. I
would recommend
logging an issue against the spec [1] for 2.1.

> What do you guys think? Useful addition for "JSF 2.1"?
> Regards,
> Jan-Kees van Andel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: