DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38487>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38487





------- Additional Comments From [EMAIL PROTECTED]  2006-02-02 19:59 -------
I can see where this kind of thing could cause problems on a big app (even if
you don't overflow memory, it can be a large startup hit to scan all the
classes).  One of the frustrations is that Tiger (JDK 1.5) does not let you
examine the bytecodes of a class to see if it has an annotation or not -- you
actually have to load it (or use a pre-deployment scan of some sort that really
complicates the build process).  You can't really wait until the class is loaded
for the first time, because it might not be you doing that load.

However, I find myself disliking the notion of requiring the user to tell Shale
where to look ... from the user perspective, it should be able to figure that
out by itself.  What would you think of the following approach?

(1) Scan all classes under WEB-INF/classes.  This is likely
    to be a relatively small total number of classes, they
    are likely to get all or mostly loaded anyway, and there
    is a high likelihood of finding annotated managed beans
    and annotated view controllers here.

(2) Scan JAR files in WEB-INF/lib that have a "META-INF/faces-config.xml"
    file in them, even if it is empty.  That will cut the scan
    down to jars that are clearly JSF-specific, so you'd skip
    things like Hibernate or most of Spring.

This approach should substantially reduce the number of classes scanned, without
requiring the app developer to do anything complicated about configuration.

What do you think?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to