+1
2011/3/24 Scott O'Bryan <[email protected]>: > Is that a +1? :D > > On Mar 24, 2011, at 4:06 PM, Leonardo Uribe <[email protected]> wrote: > >> Hi >> >> I have created these issues: >> >> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 >> >> https://issues.apache.org/jira/browse/MYFACES-3082 >> >> I agree with the proposed behavior, and I don't think do it could >> cause any problems. So from my side there is no objections about the >> artifacts proposed. Thanks for the clarification. >> >> Leonardo >> >> 2011/3/24 Andy Schwartz <[email protected]>: >>> 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 >>> >
