On Thu, Jun 11, 2009 at 4:21 PM, Pete Muir <pmuir@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).

-Dan

--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.