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

All - This issue turned up again yesterday in an Apache MyFaces thread, starting around: http://myfaces.markmail.org/search/?q=#query:+page:2+mid:te2j33f6gsbtedcb... Although Mojarra does implement the desired behavior, unfortunately it looks like the specification was never updated to match, likely because I never logged a spec issue. :-( Leonardo was kind enough to correct that: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 Can include this small but important spec tweak in 2.2?

Andy On 9/3/09 4:58 PM, 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. > > 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

On Mar 25, 2011, at 10:01 AM, Andy Schwartz wrote: All - This issue turned up again yesterday in an Apache MyFaces thread, starting around: http://myfaces.markmail.org/search/?q=#query:+page:2+mid:te2j33f6gsbtedcb... Although Mojarra does implement the desired behavior, unfortunately it looks like the specification was never updated to match, likely because I never logged a spec issue. :-( Leonardo was kind enough to correct that: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 Can include this small but important spec tweak in 2.2? I think yes, but I'm not sure if anyone but a couple of people are still monitoring this list. I'm in the process of joining the JSR-344 JSF 2.2 EG [1], and perhaps there is already a mailing list there?

I think yes, but I'm not sure if anyone but a couple of people are still > monitoring this list. I'm in the process of joining the JSR-344 JSF 2.2 EG > [1], and perhaps there is already a mailing list there? > I monitor this list, but I agree that the name jsr-314-open is whole irrelevant at this point.