Re: Scanning for annotated classes in MyFaces 2
2009/1/11 Matthias Wessendorf mat...@apache.org: On Sun, Jan 11, 2009 at 4:46 AM, Mario Ivankovits ma...@ops.co.at wrote: ;-) I really hate to wait on the boot-up. :-) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf Last week I've been playing around with a (non-Reflection) classpath scanner of my own. It's actually not that hard to write (if you have the class file format specification somewhere for reference) and my experience until now is that it's much faster than using Reflection. I have a test webapp which I deploy on Tomcat. This webapp contains about 650 classes. With reflection, it takes about 1500ms to read them all, with my custom home brewn scanner, it only takes between 300ms and 350ms. The only performance tweak I have made was a BufferedInputStream, so I'm sure there is enough room for other improvements (maybe some fork-join algorithm to support parallelism). I haven't really tested memory footprint yet, but 650 classes is still not that much. Current status (I do this in spare time ;-)): - Expose the parsed classes in a developer-friendly format, instead of the raw class file format. (it's like a lite version of the Reflection API, to keep it fast). - Read classes in jars. - Test for possible ClassLoader issues. - Allow users to specify their own searchpaths. - Package filtering. - Search/filter API to allow the developer to only load classes that implement some interface or are tagged with an annotation. If I'm satisfied with the results, we can see if it may fit into MyFaces (or maybe a reusable utility, since there are other projects that need to scan for annotations). It's not that much code and this way there is no need for an additional dependency. I'll keep you guys informed. Regards, /Jan-Kees
Re: Scanning for annotated classes in MyFaces 2
Hi Jan, Thanks for your contribution, yes this could be done without adding a dependency. We could avoid reflection stuff and use byte code exploring. Mojarra 2.0 uses code from Glassfish codebase for this byte code stuff btw. You may take a look at their implementation to give an idea. I agree that a custom scan path should fasten the app startup time a lot, usually the annotated classes belong to a certain package in our apps like com.mycompany.myproject.* Cheers, Cagatay On Sun, Jan 18, 2009 at 1:41 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: 2009/1/11 Matthias Wessendorf mat...@apache.org: On Sun, Jan 11, 2009 at 4:46 AM, Mario Ivankovits ma...@ops.co.at wrote: ;-) I really hate to wait on the boot-up. :-) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf Last week I've been playing around with a (non-Reflection) classpath scanner of my own. It's actually not that hard to write (if you have the class file format specification somewhere for reference) and my experience until now is that it's much faster than using Reflection. I have a test webapp which I deploy on Tomcat. This webapp contains about 650 classes. With reflection, it takes about 1500ms to read them all, with my custom home brewn scanner, it only takes between 300ms and 350ms. The only performance tweak I have made was a BufferedInputStream, so I'm sure there is enough room for other improvements (maybe some fork-join algorithm to support parallelism). I haven't really tested memory footprint yet, but 650 classes is still not that much. Current status (I do this in spare time ;-)): - Expose the parsed classes in a developer-friendly format, instead of the raw class file format. (it's like a lite version of the Reflection API, to keep it fast). - Read classes in jars. - Test for possible ClassLoader issues. - Allow users to specify their own searchpaths. - Package filtering. - Search/filter API to allow the developer to only load classes that implement some interface or are tagged with an annotation. If I'm satisfied with the results, we can see if it may fit into MyFaces (or maybe a reusable utility, since there are other projects that need to scan for annotations). It's not that much code and this way there is no need for an additional dependency. I'll keep you guys informed. Regards, /Jan-Kees
Re: Scanning for annotated classes in MyFaces 2
2009/1/18 Cagatay Civici cagatay.civ...@gmail.com: Hi Jan, Thanks for your contribution, yes this could be done without adding a dependency. We could avoid reflection stuff and use byte code exploring. Mojarra 2.0 uses code from Glassfish codebase for this byte code stuff btw. You may take a look at their implementation to give an idea. I'm gonna take a look at it. I was also planning to take a look at Javassist, but I think everyone probably does something similar using the DataInputStream class. That one is really useful, since it matches the terms used in the specification. I agree that a custom scan path should fasten the app startup time a lot, usually the annotated classes belong to a certain package in our apps like com.mycompany.myproject.* Yup, that definitely saves some time, since most packages aren't interesting, like application server internal classes or classes from Hibernate. There's no need to scan those.
Re: Scanning for annotated classes in MyFaces 2
On Sun, 2009-01-18 at 14:41 +0100, Jan-Kees van Andel wrote: 2009/1/11 Matthias Wessendorf mat...@apache.org: On Sun, Jan 11, 2009 at 4:46 AM, Mario Ivankovits ma...@ops.co.at wrote: ;-) I really hate to wait on the boot-up. :-) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf Last week I've been playing around with a (non-Reflection) classpath scanner of my own. It's actually not that hard to write (if you have the class file format specification somewhere for reference) and my experience until now is that it's much faster than using Reflection. I have a test webapp which I deploy on Tomcat. This webapp contains about 650 classes. With reflection, it takes about 1500ms to read them all, with my custom home brewn scanner, it only takes between 300ms and 350ms. The only performance tweak I have made was a BufferedInputStream, so I'm sure there is enough room for other improvements (maybe some fork-join algorithm to support parallelism). I haven't really tested memory footprint yet, but 650 classes is still not that much. Current status (I do this in spare time ;-)): - Expose the parsed classes in a developer-friendly format, instead of the raw class file format. (it's like a lite version of the Reflection API, to keep it fast). - Read classes in jars. - Test for possible ClassLoader issues. - Allow users to specify their own searchpaths. - Package filtering. - Search/filter API to allow the developer to only load classes that implement some interface or are tagged with an annotation. If I'm satisfied with the results, we can see if it may fit into MyFaces (or maybe a reusable utility, since there are other projects that need to scan for annotations). It's not that much code and this way there is no need for an additional dependency. 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... 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? 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... Regards, Simon
Re: Scanning for annotated classes in MyFaces 2
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
Re: Scanning for annotated classes in MyFaces 2
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
Re: Scanning for annotated classes in MyFaces 2
We could avoid reflection stuff and use byte code exploring. Mojarra 2.0 uses code from Glassfish codebase for this byte code stuff btw. You may take a look at their implementation to give an idea. eh... ? -1 on that... -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Scanning for annotated classes in MyFaces 2
eh... ? -1 on that... -M LOL! Don't worry. I won't copy their codebase. ;-) I already have a working implementation.
Re: Scanning for annotated classes in MyFaces 2
Hi Cagatay, The issue of what packages to scan is the responsibility of the specification here however. We cannot simply decide to avoid some packages in this case, we have to wait for the spec to normalize a way to define those. Regards, ~ Simon On Sun, Jan 18, 2009 at 8:50 AM, Cagatay Civici cagatay.civ...@gmail.comwrote: Hi Jan, Thanks for your contribution, yes this could be done without adding a dependency. We could avoid reflection stuff and use byte code exploring. Mojarra 2.0 uses code from Glassfish codebase for this byte code stuff btw. You may take a look at their implementation to give an idea. I agree that a custom scan path should fasten the app startup time a lot, usually the annotated classes belong to a certain package in our apps like com.mycompany.myproject.* Cheers, Cagatay On Sun, Jan 18, 2009 at 1:41 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: 2009/1/11 Matthias Wessendorf mat...@apache.org: On Sun, Jan 11, 2009 at 4:46 AM, Mario Ivankovits ma...@ops.co.at wrote: ;-) I really hate to wait on the boot-up. :-) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf Last week I've been playing around with a (non-Reflection) classpath scanner of my own. It's actually not that hard to write (if you have the class file format specification somewhere for reference) and my experience until now is that it's much faster than using Reflection. I have a test webapp which I deploy on Tomcat. This webapp contains about 650 classes. With reflection, it takes about 1500ms to read them all, with my custom home brewn scanner, it only takes between 300ms and 350ms. The only performance tweak I have made was a BufferedInputStream, so I'm sure there is enough room for other improvements (maybe some fork-join algorithm to support parallelism). I haven't really tested memory footprint yet, but 650 classes is still not that much. Current status (I do this in spare time ;-)): - Expose the parsed classes in a developer-friendly format, instead of the raw class file format. (it's like a lite version of the Reflection API, to keep it fast). - Read classes in jars. - Test for possible ClassLoader issues. - Allow users to specify their own searchpaths. - Package filtering. - Search/filter API to allow the developer to only load classes that implement some interface or are tagged with an annotation. If I'm satisfied with the results, we can see if it may fit into MyFaces (or maybe a reusable utility, since there are other projects that need to scan for annotations). It's not that much code and this way there is no need for an additional dependency. I'll keep you guys informed. Regards, /Jan-Kees
Re: Scanning for annotated classes in MyFaces 2
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.comwrote: 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
Re: Scanning for annotated classes in MyFaces 2
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
Re: Scanning for annotated classes in MyFaces 2
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. 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
Re: Scanning for annotated classes in MyFaces 2
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
Re: Scanning for annotated classes in MyFaces 2
+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 --
Re: Scanning for annotated classes in MyFaces 2
+1 for a commons.annoscan Concerning the question of how to design the API for this scanner: Sometimes there is not a fixed set of annotations to scan for (like a.g. JPA) but one doesn't even a priori know which annotations are really important. In WebBeans any user may define it's own annotations in his custom project and define e.g. a custom @StereoType @AdministratorAction. So this is a highly dynamic situation and there are 3 ways to cope with it coming to my mind: 1.) scan for all annotations and store them all for later queries. (which is the scannotation+javassist way currently used in openwebbeans) 2.) multi-pass scanning (this would be more time consuming but has a small memory footprint) 3.) scan all annotations and remove all unnecessary ones. LieGrue, strub --- Bernd Bohmann bernd.bohm...@atanion.com schrieb am So, 18.1.2009: Von: Bernd Bohmann bernd.bohm...@atanion.com Betreff: Re: Scanning for annotated classes in MyFaces 2 An: MyFaces Development dev@myfaces.apache.org Datum: Sonntag, 18. Januar 2009, 22:00 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. 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
Re: Scanning for annotated classes in MyFaces 2
When I did this for OpenEJB I put the work into a neutral place (xbean) so it could be shared by anyone who needed it. XBean is sort of a common-like dumping ground for server-ish bits and pieces we were sharing between OpenEJB, ActiveMQ, ServiceMix, Geronimo, Maven and similar projects. Between xbean-finder (secure ASM-based annotation scanner, resource finder, etc) and xbean-reflect there really isn't anything you can't do. Most of the documentation for is javadoc. This post on TSS has a nice overview: http://www.theserverside.com/news/thread.tss?thread_id=49083#250760 The annotation scanner is org.apache.xbean.finder.ClassFinder[1]. That's implemented how you detail #1. We scan the byte-code via ASM to avoid the security risks, wasted permgen space, and time associated with classloading. We even have optimizations to avoid reading all the byte code which makes scanning pretty fast. We construct a small amount of metadata on the annotations we found and cache that so multiple searches can be done more or less free of cost. It gets released pretty frequently[2] and getting patches in is easy. -David [1] http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.4.3/xbean-finder/src/main/java/org/apache/xbean/finder/ClassFinder.java [2] http://svn.apache.org/repos/asf/geronimo/xbean/tags/ On Jan 18, 2009, at 2:55 PM, Mark Struberg wrote: +1 for a commons.annoscan Concerning the question of how to design the API for this scanner: Sometimes there is not a fixed set of annotations to scan for (like a.g. JPA) but one doesn't even a priori know which annotations are really important. In WebBeans any user may define it's own annotations in his custom project and define e.g. a custom @StereoType @AdministratorAction. So this is a highly dynamic situation and there are 3 ways to cope with it coming to my mind: 1.) scan for all annotations and store them all for later queries. (which is the scannotation+javassist way currently used in openwebbeans) 2.) multi-pass scanning (this would be more time consuming but has a small memory footprint) 3.) scan all annotations and remove all unnecessary ones. LieGrue, strub --- Bernd Bohmann bernd.bohm...@atanion.com schrieb am So, 18.1.2009: Von: Bernd Bohmann bernd.bohm...@atanion.com Betreff: Re: Scanning for annotated classes in MyFaces 2 An: MyFaces Development dev@myfaces.apache.org Datum: Sonntag, 18. Januar 2009, 22:00 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. 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
Re: Scanning for annotated classes in MyFaces 2
On Sat, 2009-01-10 at 19:56 -0700, Matthias Wessendorf wrote: On Sat, Jan 10, 2009 at 11:21 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: I don't think Scannotation itself is an issue, but it has a required dependency on Javassist, which has an LGPL license. Isn't that a problem? hrm, I think not really, b/c it's not a direct dependency. I'm pretty sure that scannotation's dependency on an LGLP project is a showstopper. There is some brief info here: http://www.apache.org/legal/resolved.html I'm not sure this approach is a good one anyway. Javasisst's jar is 560kb. That's a fairly heavy dependency for such a simple task as scanning for annotations. Regards, Simon
RE: Scanning for annotated classes in MyFaces 2
Hi! -Original Message- From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] 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? Hmmm, it is a long time back we used it at least during development times it was very annoying not having specified the packages. If I remember correctly, with defining it, scanning-time drop down from something aroung 30 seconds to under 1 second. Wouldn't it be sufficient to do it that way for a first version of MyFaces 2.0? Do you think Mojarra will come up with a more sophisticated solution which bypasses the standard reflection stuff and uses something like Javasisst? I doubt. Ciao, Mario
Re: Scanning for annotated classes in MyFaces 2
Fwik Javassist uses a Mozilla Public License 1.1 not a pure LGPL (though I've not checked explicitly for the javassist version we use). MPL 1.1 is explicitly listed as appropriate license at least. Maybe we can kick scannotation, and do the scanning ourself (in a later phase). But Javassist is imho a big deal, because we don't need to class-load all classes. Otoh I have to admit that I've never did any performance/memory tests comparing them both. LieGrue, strub --- Simon Kitching skitch...@apache.org schrieb am So, 11.1.2009: Von: Simon Kitching skitch...@apache.org Betreff: Re: Scanning for annotated classes in MyFaces 2 An: MyFaces Development dev@myfaces.apache.org Datum: Sonntag, 11. Januar 2009, 12:06 On Sat, 2009-01-10 at 19:56 -0700, Matthias Wessendorf wrote: On Sat, Jan 10, 2009 at 11:21 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: I don't think Scannotation itself is an issue, but it has a required dependency on Javassist, which has an LGPL license. Isn't that a problem? hrm, I think not really, b/c it's not a direct dependency. I'm pretty sure that scannotation's dependency on an LGLP project is a showstopper. There is some brief info here: http://www.apache.org/legal/resolved.html I'm not sure this approach is a good one anyway. Javasisst's jar is 560kb. That's a fairly heavy dependency for such a simple task as scanning for annotations. Regards, Simon
RE: Scanning for annotated classes in MyFaces 2
Hi! not sure on the PERF, but if it is really (proven) the case, I am with you. Well... startup time isn't really a big problem, right? :-) Is that ironic? In projects with 3000 classes and 60 jar files you are up to 30 seconds, or even more, scanning time. Under load, with shale, I saw scanning times of 60 seconds. This _will_ drive you crazy! Ciao, Mario
Re: Scanning for annotated classes in MyFaces 2
Yep, I should have checked the original statement. The javassist website here: http://www.jboss.org/javassist/ states clearly that: quote License: You can choose either MPL or LGPL. /quote Surprising for a jboss project, but the website clearly says so. The MPL is no problem. So using Scannotation is also fine. I'm still not convinced that adding a 560kb dependency for such a simple task is optimal, but simply getting *any* solution in place for myfaces is better than doing multiple scans. It can always be further improved later.. Regards, Simon On Sun, 2009-01-11 at 11:45 +, Mark Struberg wrote: Fwik Javassist uses a Mozilla Public License 1.1 not a pure LGPL (though I've not checked explicitly for the javassist version we use). MPL 1.1 is explicitly listed as appropriate license at least. Maybe we can kick scannotation, and do the scanning ourself (in a later phase). But Javassist is imho a big deal, because we don't need to class-load all classes. Otoh I have to admit that I've never did any performance/memory tests comparing them both. LieGrue, strub --- Simon Kitching skitch...@apache.org schrieb am So, 11.1.2009: Von: Simon Kitching skitch...@apache.org Betreff: Re: Scanning for annotated classes in MyFaces 2 An: MyFaces Development dev@myfaces.apache.org Datum: Sonntag, 11. Januar 2009, 12:06 On Sat, 2009-01-10 at 19:56 -0700, Matthias Wessendorf wrote: On Sat, Jan 10, 2009 at 11:21 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: I don't think Scannotation itself is an issue, but it has a required dependency on Javassist, which has an LGPL license. Isn't that a problem? hrm, I think not really, b/c it's not a direct dependency. I'm pretty sure that scannotation's dependency on an LGLP project is a showstopper. There is some brief info here: http://www.apache.org/legal/resolved.html I'm not sure this approach is a good one anyway. Javasisst's jar is 560kb. That's a fairly heavy dependency for such a simple task as scanning for annotations. Regards, Simon
Re: Scanning for annotated classes in MyFaces 2
I've checked mojarra 2.0 some time ago to see how do they implemented this, well they're using reflection/class way. Spring's scanning mechanism also gives out of memory if you dont specify a sub package name to scan. So, my thought is to implement this in myfaces, it's not a complicated task as we all discussed. And if we do implement it, we get the advantage of tuning it for better performance in a web environment. C.C. On Sun, Jan 11, 2009 at 11:46 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! not sure on the PERF, but if it is really (proven) the case, I am with you. Well... startup time isn't really a big problem, right? :-) Is that ironic? In projects with 3000 classes and 60 jar files you are up to 30 seconds, or even more, scanning time. Under load, with shale, I saw scanning times of 60 seconds. This _will_ drive you crazy! Ciao, Mario
Re: Scanning for annotated classes in MyFaces 2
My 2 cents: Don't load classes to use java.lang.reflect on it:
- What if a class does something bad (or just about anything) in a static
initializer?
For example try to run the code below. It will EXIT THE VM
- Can you be sure that those classes are unloaded again?
- Performance: It is _faster_ to use a library (like javassist), because the
class loader must effectively parse the byte code, too, plus then do a lot
more (like validation).
package com.acme.foo;
class Exit {
static {
System.exit(-1);
}
}
public class Main {
public static void main(String[] args) throws InterruptedException,
ClassNotFoundException {
Class? clazz = Class.forName(com.acme.foo.Exit);
while(true) {
Thread.sleep(1000);
System.out.println(System.currentTimeMillis() / 1000);
}
}
}
Cagatay Civici wrote:
I've checked mojarra 2.0 some time ago to see how do they implemented
this, well they're using reflection/class way.
Spring's scanning mechanism also gives out of memory if you dont specify
a sub package name to scan.
So, my thought is to implement this in myfaces, it's not a complicated
task as we all discussed. And if we do implement it, we get the
advantage of tuning it
for better performance in a web environment.
C.C.
On Sun, Jan 11, 2009 at 11:46 AM, Mario Ivankovits ma...@ops.co.at
mailto:ma...@ops.co.at wrote:
Hi!
not sure on the PERF, but if it is really (proven) the case, I am
with
you.
Well... startup time isn't really a big problem, right? :-)
Is that ironic?
In projects with 3000 classes and 60 jar files you are up to 30
seconds, or even more, scanning time.
Under load, with shale, I saw scanning times of 60 seconds.
This _will_ drive you crazy!
Ciao,
Mario
Re: Scanning for annotated classes in MyFaces 2
On Sun, Jan 11, 2009 at 4:46 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! not sure on the PERF, but if it is really (proven) the case, I am with you. Well... startup time isn't really a big problem, right? :-) Is that ironic? ;-) I really hate to wait on the boot-up. :-) In projects with 3000 classes and 60 jar files you are up to 30 seconds, or even more, scanning time. Under load, with shale, I saw scanning times of 60 seconds. This _will_ drive you crazy! Ciao, Mario -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Scanning for annotated classes in MyFaces 2
2009/1/7 Mario Ivankovits ma...@ops.co.at: -Original Message- From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] Sent: Wednesday, January 07, 2009 8:15 AM To: dev@myfaces.apache.org Subject: Re: Scanning for annotated classes in MyFaces 2 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. 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
Re: Scanning for annotated classes in MyFaces 2
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
Re: Scanning for annotated classes in MyFaces 2
I see scannoation in openwebbeans, anyone tried it? As far as I know it's a one man project and dont know if he still maintains it. I think reflection.class stuff is problematic if you dont limit the package name to be scanned. On Sat, Jan 10, 2009 at 4:44 PM, Matthias Wessendorf mat...@apache.orgwrote: 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
Re: Scanning for annotated classes in MyFaces 2
On Sat, Jan 10, 2009 at 10:09 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: I see scannoation in openwebbeans, anyone tried it? As far as I know it's a one man project and dont know if he still maintains it. ah, so perhaps guice over scannoation ? -M I think reflection.class stuff is problematic if you dont limit the package name to be scanned. On Sat, Jan 10, 2009 at 4:44 PM, Matthias Wessendorf mat...@apache.org wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Scanning for annotated classes in MyFaces 2
On Sat, Jan 10, 2009 at 10:31 AM, Matthias Wessendorf mat...@apache.org wrote: On Sat, Jan 10, 2009 at 10:09 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: I see scannoation in openwebbeans, anyone tried it? As far as I know it's a one man project and dont know if he still maintains it. ah, so perhaps guice over scannoation ? oh, I see it's (scannotation) from Bill Burke. and the license is fine (ASL 2) as well. -M -M I think reflection.class stuff is problematic if you dont limit the package name to be scanned. On Sat, Jan 10, 2009 at 4:44 PM, Matthias Wessendorf mat...@apache.org wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Scanning for annotated classes in MyFaces 2
I don't think Scannotation itself is an issue, but it has a required dependency on Javassist, which has an LGPL license. Isn't that a problem? Using Scannotation, however, would definitely ease development. /Jan-Kees 2009/1/10 Matthias Wessendorf mat...@apache.org: On Sat, Jan 10, 2009 at 10:31 AM, Matthias Wessendorf mat...@apache.org wrote: On Sat, Jan 10, 2009 at 10:09 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: I see scannoation in openwebbeans, anyone tried it? As far as I know it's a one man project and dont know if he still maintains it. ah, so perhaps guice over scannoation ? oh, I see it's (scannotation) from Bill Burke. and the license is fine (ASL 2) as well. -M -M I think reflection.class stuff is problematic if you dont limit the package name to be scanned. On Sat, Jan 10, 2009 at 4:44 PM, Matthias Wessendorf mat...@apache.org wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Scanning for annotated classes in MyFaces 2
Feel free to use my code for facelets annotation deployment: http://jsf-comp.sourceforge.net/components/facelets-deployment/index.html http://jsf-comp.svn.sourceforge.net/svnroot/jsf-comp/trunk/facelets/annotation-deployment/ http://jsf-comp.svn.sourceforge.net/viewvc/jsf-comp/trunk/facelets/annotation-deployment/src/main/java/net/sf/jsfcomp/facelets/deploy/ http://jsf-comp.svn.sourceforge.net/viewvc/jsf-comp/trunk/facelets/annotation-deployment/src/main/java/net/sf/jsfcomp/facelets/deploy/FaceletAnnotationParser.java?view=markup TinyURL of the last URL: *http://tinyurl.com/9xdgph* This last java class does all the main scanning work. It isn't reusable for what you need, but I don't see the need for a 3rd party library as scanning code is pretty easy. Writing a custom one for MyFaces will probably have better performance than a reusable one that would probably have more flexibility code in it. -Andrew On Tue, Jan 6, 2009 at 1:32 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, The JSF 2.0 spec requires an implementation to support several annotations, like @ManagedBean. Has anyone already thought of a possible implementation for this requirement? IMHO, there is only one option, and that is scanning the classpath at application startup, because you don't want the overhead with every EL expression. But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. And second, how to scan? Reading each *.class file, then creating a Class instance and then using reflection to scan for annotations is probably very expensive. Not only the processing time, but I think it will also become a memory issue because every class in the classpath will be loaded into memory. Scanning the plain *.class files is probably not very practical. I don't know, never tried it, but the class files I've seen don't look very appealing. :-) It might be an idea to look at Scannotation, which is an open source library for scanning jar files for annotations. It works quite good and it has the advantage of being very efficient because it doesn't use the default Class/Reflection mechanism. http://sourceforge.net/projects/scannotation/ The project homepage says it has an Apache 2.0 license, but at the same time it has a dependency on Javassist (licensed LGPL or MPL) and the source files don't contain any headers, so it may be not an option. I don't know, IANAL. I was playing around with a @ManagedBean annotation parser, but It may be a good idea to have a discussion on this subject since it probably has some impact. What do you think? Regards, Jan-Kees
Re: Scanning for annotated classes in MyFaces 2
On Sat, Jan 10, 2009 at 11:21 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: I don't think Scannotation itself is an issue, but it has a required dependency on Javassist, which has an LGPL license. Isn't that a problem? hrm, I think not really, b/c it's not a direct dependency. Using Scannotation, however, would definitely ease development. +1 on what I read about it /Jan-Kees 2009/1/10 Matthias Wessendorf mat...@apache.org: On Sat, Jan 10, 2009 at 10:31 AM, Matthias Wessendorf mat...@apache.org wrote: On Sat, Jan 10, 2009 at 10:09 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: I see scannoation in openwebbeans, anyone tried it? As far as I know it's a one man project and dont know if he still maintains it. ah, so perhaps guice over scannoation ? oh, I see it's (scannotation) from Bill Burke. and the license is fine (ASL 2) as well. -M -M I think reflection.class stuff is problematic if you dont limit the package name to be scanned. On Sat, Jan 10, 2009 at 4:44 PM, Matthias Wessendorf mat...@apache.org wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Scanning for annotated classes in MyFaces 2
On Sat, Jan 10, 2009 at 11:34 AM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: Feel free to use my code for facelets annotation deployment: http://jsf-comp.sourceforge.net/components/facelets-deployment/index.html http://jsf-comp.svn.sourceforge.net/svnroot/jsf-comp/trunk/facelets/annotation-deployment/ http://jsf-comp.svn.sourceforge.net/viewvc/jsf-comp/trunk/facelets/annotation-deployment/src/main/java/net/sf/jsfcomp/facelets/deploy/ http://jsf-comp.svn.sourceforge.net/viewvc/jsf-comp/trunk/facelets/annotation-deployment/src/main/java/net/sf/jsfcomp/facelets/deploy/FaceletAnnotationParser.java?view=markup TinyURL of the last URL: http://tinyurl.com/9xdgph This last java class does all the main scanning work. It isn't reusable for what you need, but I don't see the need for a 3rd party library as scanning code is pretty easy. Writing a custom one for MyFaces will probably have better performance than a reusable one that would probably have more flexibility code in it. not sure on the PERF, but if it is really (proven) the case, I am with you. Well... startup time isn't really a big problem, right? :-) -Andrew On Tue, Jan 6, 2009 at 1:32 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, The JSF 2.0 spec requires an implementation to support several annotations, like @ManagedBean. Has anyone already thought of a possible implementation for this requirement? IMHO, there is only one option, and that is scanning the classpath at application startup, because you don't want the overhead with every EL expression. But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. And second, how to scan? Reading each *.class file, then creating a Class instance and then using reflection to scan for annotations is probably very expensive. Not only the processing time, but I think it will also become a memory issue because every class in the classpath will be loaded into memory. Scanning the plain *.class files is probably not very practical. I don't know, never tried it, but the class files I've seen don't look very appealing. :-) It might be an idea to look at Scannotation, which is an open source library for scanning jar files for annotations. It works quite good and it has the advantage of being very efficient because it doesn't use the default Class/Reflection mechanism. http://sourceforge.net/projects/scannotation/ The project homepage says it has an Apache 2.0 license, but at the same time it has a dependency on Javassist (licensed LGPL or MPL) and the source files don't contain any headers, so it may be not an option. I don't know, IANAL. I was playing around with a @ManagedBean annotation parser, but It may be a good idea to have a discussion on this subject since it probably has some impact. What do you think? Regards, Jan-Kees -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: Scanning for annotated classes in MyFaces 2
I can help you with it if you want to. I find it an interesting subject. If you could just point me to the main scanner classes and methods in Shale, I'll find my way from there. Regards, Jan-Kees Mario Ivankovits wrote: -Original Message- From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] Sent: Wednesday, January 07, 2009 8:15 AM To: dev@myfaces.apache.org Subject: Re: Scanning for annotated classes in MyFaces 2 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. 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 -- View this message in context: http://www.nabble.com/Scanning-for-annotated-classes-in-MyFaces-2-tp21318418p21330557.html Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: Scanning for annotated classes in MyFaces 2
Hi Jan-Kees, I think it's ok for Apache projects to depend on external libraries that are not licensed under ASL 2.0. However that would be some extra dependencies for MyFaces and we try to minimize those. On the other hand the gain might worth it in this case imho if those libraries are deployed in common public Maven repositories. Thank for your help with MyFaces 2.0 ~ Simon On Tue, Jan 6, 2009 at 3:32 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, The JSF 2.0 spec requires an implementation to support several annotations, like @ManagedBean. Has anyone already thought of a possible implementation for this requirement? IMHO, there is only one option, and that is scanning the classpath at application startup, because you don't want the overhead with every EL expression. But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. And second, how to scan? Reading each *.class file, then creating a Class instance and then using reflection to scan for annotations is probably very expensive. Not only the processing time, but I think it will also become a memory issue because every class in the classpath will be loaded into memory. Scanning the plain *.class files is probably not very practical. I don't know, never tried it, but the class files I've seen don't look very appealing. :-) It might be an idea to look at Scannotation, which is an open source library for scanning jar files for annotations. It works quite good and it has the advantage of being very efficient because it doesn't use the default Class/Reflection mechanism. http://sourceforge.net/projects/scannotation/ The project homepage says it has an Apache 2.0 license, but at the same time it has a dependency on Javassist (licensed LGPL or MPL) and the source files don't contain any headers, so it may be not an option. I don't know, IANAL. I was playing around with a @ManagedBean annotation parser, but It may be a good idea to have a discussion on this subject since it probably has some impact. What do you think? Regards, Jan-Kees
Re: Scanning for annotated classes in MyFaces 2
I think we should avoid scannotation, not that it's bad but because it's a dependency. MyFaces already has more dependencies compared to mojarra afaik and increasing those doesn't sound good. Classpath scanning is a tricky business and it's good both performance and computing wise to limit the scanned packages like spring does(scan=com.myproject.*) but I dont think this kind of behavior is in the 2.0 spec. On Tue, Jan 6, 2009 at 8:47 PM, Simon Lessard simon.lessar...@gmail.comwrote: Hi Jan-Kees, I think it's ok for Apache projects to depend on external libraries that are not licensed under ASL 2.0. However that would be some extra dependencies for MyFaces and we try to minimize those. On the other hand the gain might worth it in this case imho if those libraries are deployed in common public Maven repositories. Thank for your help with MyFaces 2.0 ~ Simon On Tue, Jan 6, 2009 at 3:32 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, The JSF 2.0 spec requires an implementation to support several annotations, like @ManagedBean. Has anyone already thought of a possible implementation for this requirement? IMHO, there is only one option, and that is scanning the classpath at application startup, because you don't want the overhead with every EL expression. But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. And second, how to scan? Reading each *.class file, then creating a Class instance and then using reflection to scan for annotations is probably very expensive. Not only the processing time, but I think it will also become a memory issue because every class in the classpath will be loaded into memory. Scanning the plain *.class files is probably not very practical. I don't know, never tried it, but the class files I've seen don't look very appealing. :-) It might be an idea to look at Scannotation, which is an open source library for scanning jar files for annotations. It works quite good and it has the advantage of being very efficient because it doesn't use the default Class/Reflection mechanism. http://sourceforge.net/projects/scannotation/ The project homepage says it has an Apache 2.0 license, but at the same time it has a dependency on Javassist (licensed LGPL or MPL) and the source files don't contain any headers, so it may be not an option. I don't know, IANAL. I was playing around with a @ManagedBean annotation parser, but It may be a good idea to have a discussion on this subject since it probably has some impact. What do you think? Regards, Jan-Kees
RE: Scanning for annotated classes in MyFaces 2
Hi! But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. What ever the spec says, we definitely should provide a configuration parameter in web.xml where one can configure the packages to scan, else startup times of your webapp will be VERY bad. I had this in the past with shale-annotation. There I added such configuration already. We can strip the scanning/parsing out there - I'll contribute if required. Ciao, Mario
Re: Scanning for annotated classes in MyFaces 2
hello mario, sounds good to me regards, gerhard 2009/1/7 Mario Ivankovits ma...@ops.co.at Hi! But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. What ever the spec says, we definitely should provide a configuration parameter in web.xml where one can configure the packages to scan, else startup times of your webapp will be VERY bad. I had this in the past with shale-annotation. There I added such configuration already. We can strip the scanning/parsing out there - I'll contribute if required. Ciao, Mario
Re: Scanning for annotated classes in MyFaces 2
Hi, 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. Jan-Kees Gerhard Petracek wrote: hello mario, sounds good to me regards, gerhard 2009/1/7 Mario Ivankovits ma...@ops.co.at Hi! But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. What ever the spec says, we definitely should provide a configuration parameter in web.xml where one can configure the packages to scan, else startup times of your webapp will be VERY bad. I had this in the past with shale-annotation. There I added such configuration already. We can strip the scanning/parsing out there - I'll contribute if required. Ciao, Mario -- View this message in context: http://www.nabble.com/Scanning-for-annotated-classes-in-MyFaces-2-tp21318418p21326014.html Sent from the My Faces - Dev mailing list archive at Nabble.com.
RE: Scanning for annotated classes in MyFaces 2
-Original Message- From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] Sent: Wednesday, January 07, 2009 8:15 AM To: dev@myfaces.apache.org Subject: Re: Scanning for annotated classes in MyFaces 2 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. 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
