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
