[jsr-314-open] Metadata complete jar files
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