+1 regards, gerhard
2009/1/18 Matthias Wessendorf <mat...@apache.org> > On Sun, Jan 18, 2009 at 1:00 PM, Bernd Bohmann > <bernd.bohm...@atanion.com> wrote: > > Hello, > > > > perhaps the annotation scanning was already solved by openejb? > > We should try to create a common annotation module for apache projects > > like openejb, tomcat, cxf and myfaces. > and openwebbeans > > +1 > > > > Regards > > > > Bernd > > > > > > > > Gerhard Petracek schrieb: > >> 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 > >>>>> > >>>> > >> > >> > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
