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]