>>> It might be smart to put this Shale code in a separate project. For >>> example >>> in Commons, since there are several Apache projects that need to scan >>> for >>> annotations, like EJB3 and JPA projects.
there is something on the new "open web beans" podling (in the incubator) or, take a look a google guice? I think the startup is pretty fast and the dependency shouldn't really be a show stopper. Guice is ASL2, btw. -M >> >> >> Yeah, I thought the same too. >> What would be great would be some sort of "annotation scanner" where you can >> register a "scanning job" for system startup so that the classpath scanning >> has to take place only once and the scanning jobs get called back about the >> results. >> >> Sure, if a scanning job registers something like "**" all packages get >> scanned and startup time is slow again, but this is on the responsibility of >> the developer then. >> >> >> I can help to startup a commons sandbox project and to work out a >> specification for the library, but my spare time for coding is very low :-( >> >> Ciao, >> Mario >> >> > > Mario, I've been looking at the Shale code that handles the annotation > scanning, but I saw it uses Reflection and standard Java ClassLoaders > for scanning the classpath for JSF artifacts. What's your experience > with the performance of this? Does Shale heavily rely on specifying a > base package to be efficient? > > /Jan-Kees > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
