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 >>
