A simple pluggable API sounds like a reasonable approach to me. For
some situations, a pure reflection scanner might work better. For
others, it won't scale. You might need to temporarily switch to a
different scanner to determine if it's the cause of some particular
bug. Or perhaps the target appserver itself provides some form of
high-optimized scanner.
On Fri, Feb 27, 2009 at 4:31 PM, Curtiss Howard
<curtiss.how...@gmail.com> wrote:
> Hi all,
>
> I'd like to take this opportunity to address some concerns I have with
> the way annotation processing is done. I take interest in this
> subject due to the extensive amount of work I have done in this area,
> and I feel that I can shed some light on possible performance issues.
> This message is mainly addressed to Jan-Kees van Andel as he is doing
> the work on the MyFaces annotation processing engine, but of course
> community input is always welcome. I will address some points that JK
> raised in a previous thread on the user mailing list:
>
> "- Currently, I'm using the xbean-finder library from Geronimo for the
> processing stuff. This library uses ASM under the hood which worries
> me, since ASM is a widely used library and it has lead to many
> classloading issues because of other frameworks packaging different
> versions of ASM. "
>
> I would strongly recommend that MyFaces does NOT move away from doing
> class scanning with ASM (or some other bytecode scanning library) as
> the only other alternative is pure reflection and the performance in
> that case does not scale well at all.
>
> "- I have also created an annotation scanner of my own, which is
> actually quite fast and doesn't have a dependency on any library,
> except Java. "
>
> Since this scanner has no external dependencies, I'm tempted to
> believe this is a reflective scanner. If not, did you write a
> bytecode scanning library?
>
> "I don't think that making the annotation scanning code pluggable is
> very useful since the xbean-finder library is already very easy to
> use. "
>
> The one major concern with the xbean-finder library is that it
> assembles a list of all the JARs on the classpath and scans all of
> them. This is bad for a number of reasons:
>
> 1. The number of JARs to scan is _enormous_ in a typical customer
> application running on a typical (i.e., bloated) appserver.
> 2. By indiscriminately scanning JARs that are on the classpath but not
> necessarily part of the application you open yourself up to
> potentially pulling in random annotations that could have negative
> effects on the application.
>
> Now, xbean-finder has a way for you to specify that you only want to
> include JARs up to a certain point in the Classloader hierarchy, but
> FaceConfigurator is not currently doing this :) and there is at least
> one appserver I know of where even that approach wouldn't work since
> applications are allowed to reference "shared libraries" that sit
> apart from the normal classloader hierarchy. At a minimum, I think
> FacesConfigurator would need to allow pluggability for integrators to
> decide how to populate xbean-finder with its set of Classloaders.
>
> In terms of pluggability, what I'd like to see is a simple interface
> that abstracts away annotation scanning. This would be good for two
> reasons: first, appservers that integrate MyFaces would be able to
> take advantage of performance benefits that may arise from tight
> coupling with their runtime (not to mention that they may need to
> customize the classpath that xbean-finder or the like searches). And
> second, this is a good practice in general as MyFaces shouldn't
> necessarily be tied to xbean-finder. There may very well be better
> solutions, and being able to plug them in would help in the long run.
>
> My proposal for such an interface is this:
>
> public interface AnnotationScanner {
> public Collection<Class> getAnnotatedClasses (Class annotationClass);
> public Collection<Method> getAnnotatedMethods (Class annotationClass);
> public Collection<Field> getAnnotatedFields (Class annotationClass);
> public Collection<Package> getAnnotatedPackages (Class
> annotationClass);
> }
>
> This interface is very similar to xbean-finder, and with good reason:
> as you stated, it's a simple API to work with. FacesConfigurator
> would need minimal changes to adapt to this interface. The advantage
> here is, again, more freedom in how annotation scanning is performed.
>
> Also, I would propose a factory that creates these instances with the
> FacesContext (that should be enough context for implementers to work
> with).
>
> Please let me know what you think. Thanks,
>
>
> Curtiss Howard
>
