[jsr-314-open] Metadata complete jar files

[Pete Muir]

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