[jsr-314-open] annotation scanning (was Re: Meeting minutes from EG face-to-face at Sun's SF office post-JavaOne)

[Pete Muir]

On 11 Jun 2009, at 21:48, Dan Allen wrote:

> On Thu, Jun 11, 2009 at 4:21 PM, Pete Muir <pmuir at redhat.com> wrote:
> 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.
>
> Exactly. The very definition of a scan is widely divergent. Seam  
> (and Web Beans) have taken the approach of looking for a marker file  
> using getResources() and scanning the associated classpaths. I  
> brought up this style in the meeting.
>
> The approach by JSF is to look in WEB-INF/classes and in each JAR  
> file in WEB-INF/lib. This is problematic if you happen to have an  
> external classpath. One case is when you run Jetty from Maven. A  
> more common case is when you have another EE module, such as an EJB- 
> JAR.
>
> The Servlet spec seems to be suggesting that every classpath visible  
> to the application is going to be scanned, which is terribly  
> reckless in my opinion (I'm sure others).
>
> So we need consistency in what is scanned, and then need a way to  
> leverage a container-provided scanning mechanism, if available  
> (obviously in a standalone environment you have to bring your own  
> scanner).

This was proposed at one point for EE6, but has vanished into the mire  
somewhere ;-)

Definitely one for EE7 I think. I've cc'd Jason Greene, the Red Hat  
rep on the EE EG so he is aware that of this point.