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: http://issues.apache.org/jira/browse/MYFACES-2386 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 (http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/validator/_ExternalSpecifications.java?revision=829526&view=markup) 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. ;-) What do you guys think? Useful addition for "JSF 2.1"? Regards, Jan-Kees van Andel
