myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Starets <max.star...@oracle.com>
Subject Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Date Fri, 25 Mar 2011 15:25:43 GMT
Thanks, Leonardo!

You rock!

Max

On 3/24/2011 6:06 PM, Leonardo Uribe 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 <andy.g.schwartz@gmail.com>:
>   
>> 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
>>
>>     

Mime
View raw message