Hi Andy
On 3 Sep 2009, at 15:58, Andy Schwartz wrote:
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.
I think this is the correct approach, and the way it should always
have been.
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