Re: [jsr-314-open] Meeting minutes from EG face-to-face at Sun's SF office post-JavaOne
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.