Hey Andy,
I'm wondering if there should be a TCK check for this as well since the
behavior has come into question.
Scott
On 03/24/2011 03:57 PM, Andy Schwartz wrote:
Gang -
Looking back at the EG emails, I realize now that I dropped the ball
on making sure that my proposed changes actually made it into the
spec.
Here was my original email ("Metadata complete jar files") from
Septeber 3, 2009:
Gang -
Section 11.5.1 of the spec defines the following annotation scanning behavior:
Requirements for scanning of classes for annotations
* If the<faces-config> element in the WEB-INF/faces-config.xml file contains
metadata-complete attribute whose value is “true”, the implementation must not
perform annotation scanning on any classes except for those classes provided by the
implementation itself. Otherwise, continue as follows.
* If the runtime discovers a conflict between an entry in the Application
Configuration Resources and an annotation, the entry in the Application
Configuration Resources takes precedence.
* All classes in WEB-INF/classes must be scanned.
* For every jar in the application's WEB-INF/lib directory, if the jar contains
a “META-INF/faces-config.xml” file or a file that matches the regular
expression “.*\.faces-config.xml” (even an empty one), all classes in that jar
must be scanned.
Since application developers have the ability to disable annotation scanning at
a global level, this means that any component set that wants to support this
mode would need to provide a metadata complete faces-config.xml file. I don't
think this is a hardship for most component vendors, since presumably component
vendors are going to want to provide design-time metadata (eg. JSR-276
metadata), which, for the moment, requires a faces-config.xml file anyway.
A question that came up here is whether we can tweak section 11.5.1 to accommodate
metadata complete jar files. That is, can we specify that any jar that contains a
faces-config.xml with a metadata-complete="true" attribute would not be
scanned? This would allow component vendors to indicate that their jar files are metadata
complete, and thus avoid the cost of annotation scanning for the contents of the jar.
Note that while the annotation scan is typically a one time hit (during
application startup), design-time tools may end up starting/stopping JSF
repeatedly during the development process. Thus, avoiding unnecessary scanning
should provide for a more efficient development experience.
Any thoughts on whether we could/should make this change? Does anyone know of
reasons why we avoided specifying this originally?
Also - if we agree to make this change, is this small enough that we could get
this into the the next MR?
Andy
Both Dan and Pete responded in support. There were no other responses
on the EG list.
I should have followed up to make sure that the spec update happened,
but apparently never did. I will do that now. :-)
Sorry about the confusion. :-(
Andy
