[jsr-314-open] annotation scanning (was Re: Meeting minutes from EG face-to-face at Sun's SF office post-JavaOne)
3:48 p.m.
On Thu, Jun 11, 2009 at 4:21 PM, Pete Muir <pmuir(a)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.
4:11 p.m.
On 11 Jun 2009, at 21:48, Dan Allen wrote:
On Thu, Jun 11, 2009 at 4:21 PM, Pete Muir <pmuir(a)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.
6174
days inactive
6174
days old
jsr-314-open-mirror@lists.jboss.org
1 comments
2 participants
participants (2)
-
Dan Allen -
Pete Muir