[jsr-314-open] Meeting minutes from EG face-to-face at Sun's SF office post-JavaOne

[Pete Muir]

As I understand it, the problem here (especially with the Servlet  
spec) is that there is no limiting which jars can contain annotations,  
so every class must be checked. There are various optimizations you  
can do (the obvious one is to exclude all known library jars which  
don't contain annotations). NB this isn't such a problem with 299 as  
it carefully limits which jars need to be scanned.

You can do a centralized annotation scan using a vendor specific SPI  
which each container using the implementation will implement (we will  
do something like this for Web Beans), but there is definitely value  
in standardizing an API for this for the whole of EE (I guess EE7 now)  
which can be used for portable frameworks.

On 11 Jun 2009, at 20:37, Dan Allen wrote:

> A lengthly discussion pursued regarding annotation scanning
>
> One concern is that various EE specs need to scan for annotations,  
> which may lead to multiple scan passes, and possibly inconsistent  
> behavior regarding how paths to scan/exclude are determined.  To  
> avoid performing an extra scan, servlet EG members recommended that  
> JSF implementations leverage the new ServletContainerInitializer  
> API.  This allows the servlet container to call JSF implementations  
> back with any classes that may be of interest to JSF (as specified  
> via the @HandlesTypes annotation).  JSF 2.0 implementations do not/ 
> should not require Servlet 3.0, but could possibly leverage this  
> mechanism when running in 3.0 containers.
>
> Dan raised concern that the servlet spec is too narrow to deal with  
> all annotation scanning needed in Java EE, so likely this is only  
> going to be a partial optimization. He mentioned that the Java EE EG  
> and the JSR-299 EG should be brought into this discussion.