hello, i agree with simon.
regards, gerhard 2009/1/18 Simon Lessard <simon.lessar...@gmail.com> > Hi again, > > Actually, much more packages have to be scanned. The goal of those > annotation is 0-Config, so a faces-config.xml might not even be needed > anymore in the libraries. Anyway, before implementing any kind of package > filter, I would wait for the final spec version, as long as the scanner is > designed to easily include such filter if/when the need arise. > > > Regards, > > ~ Simon > > > On Sun, Jan 18, 2009 at 11:15 AM, Cagatay Civici <cagatay.civ...@gmail.com > > wrote: > >> I also have some questions for the JSF 2.0 EG, like what classpaths >>> need to be scanned by default. Or the policy of dealing with runtime >>> invisible annotations (I can read them, but Reflection cannot). I'm >>> also interested in general rules regarding class/method signatures. >>> For example, do you need to implement a specific interface when >>> annotating a class with @FacesComponent? >> >> >> Afaik, only jars with a faces-config.xml under META-INF are subject to >> scan in classpath. >> >> On Sun, Jan 18, 2009 at 4:01 PM, Jan-Kees van Andel < >> jankeesvanan...@gmail.com> wrote: >> >>> > That sounds great. >>> > >>> > What is your general approach? Just read in the class as byte[], then >>> > use the class-file-format rules to get to the annotations sections on >>> > the class and the methods? From my quick scan of the classfile spec it >>> > seemed reasonably easy to do that... >>> > >>> >>> This line is the important one: >>> DataInputStream dis = new DataInputStream(new BufferedInputStream(new >>> FileInputStream(classFile))); >>> >>> The DataInputStream is responsible for delivering the bytecode to me >>> as easy-to-read ints, shorts and bytes. >>> The first chapter of this document specifies the relation between the >>> terms used in the spec and the DataInputStream API. >>> >>> http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf >>> >>> From there it's just reading each field, which is quite cumbersome and >>> hard to get right the first time, because you need to read the spec >>> very carefully. For example, when reading a double or long, you need >>> to skip the next byte. Forget this and you get annoying errors, like >>> EOF or variables that contain nonsense. >>> But when you get the hang of it, it's not that hard. >>> >>> > I'd be interested to know the actual requirements that MyFaces has for >>> > such a scanner. For example, does it ever need to look for annotations >>> > on methods when the class itself is not annotated? >>> > >>> >>> I also have some questions for the JSF 2.0 EG, like what classpaths >>> need to be scanned by default. Or the policy of dealing with runtime >>> invisible annotations (I can read them, but Reflection cannot). I'm >>> also interested in general rules regarding class/method signatures. >>> For example, do you need to implement a specific interface when >>> annotating a class with @FacesComponent? >>> >>> > Your comment about "expose parsed classes" seems to imply that you are >>> > providing some kind of DOM-style API. I would have thought that a >>> > SAX-style API would be better, ie various bits of code interested in >>> > annotations registers callbacks for annotations it cares about with the >>> > "scanner". Then the scanner scans all jars in the classpath and when >>> > something is found that matches a "registered" annotation, then it >>> > invokes the appropriate callback. That approach would minimise memory >>> > usage, and I can't see where we would need anything dom-like... >>> >>> Well, for performance reasons you would like a SAX style API, but >>> afaics, the class file format is not very developer friendly. Maybe it >>> just takes some getting used to, but on first sight, it looks less >>> intuitive than SAX parsing an XML document. For example, class >>> attributes are placed below the fields and methods, so you don't know >>> the class annotations when reading through the fields and methods. >>> That's not very intuitive for a developer. >>> >>> My plan was not to fully initialize the classes, but just fill them >>> with the bytes read. This way, I get a little bit more structure so I >>> don't have to think in bits and bytes too much. The heavy work will be >>> done lazily. For example, I don't initialize the classes' fields >>> unless the user asks for it, probably resulting in less memory usage >>> and better performance than a fully fledged DOM model. >>> >>> But there's only one way to find out and that's implementing and testing >>> it. >>> >>> I'm gonna look at a SAX style API. Maybe it's not as bad as I first >>> thought... >>> >>> Regards, >>> >>> /Jan-Kees >>> >> >> > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
