Hoi Simo! Yup, looks pretty fine from a users perspective. I'm just not sure if this can be done in a performance intense scenario. We would need to do a few performance tests upfront. Remember we often have 50.000++ classes to scan through. And every Class has ~30 methods and fields w Annotations + method params + Annotations, ... If you would really invoke this filter method for each and every structure element, then you would get performance problems pretty soon.
Of course we need some kind of filtering, but we must be careful and do lots of performance tests upfront to not propagate an non-performing pattern. LieGrue, strub --- On Fri, 7/22/11, Simone Tripodi <simonetrip...@apache.org> wrote: > From: Simone Tripodi <simonetrip...@apache.org> > Subject: Re: [sandbox] class scanning + karma requests > To: "Commons Developers List" <dev@commons.apache.org> > Date: Friday, July 22, 2011, 3:54 PM > Hi Mark!!! > For meiyo APIs I'd like to keep I mean end-user APIs; as > Matt > suggested you, since you didn't hear about the already > existing > sandbox component before, the most interesting parts of > meiyo are the > filtering/callback APIs, expressed via EDSL. Have a look at > the simple > included testcase[1] to see how they make clear its usage > to end user > - of course they can be improved!!! - and I bet should not > a big issue > integrating them in your more efficient engine :P > Looking forward to hear from you soon, all the best! > Simo > > [1] http://s.apache.org/YIF > [2] http://s.apache.org/5Gt > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Jul 22, 2011 at 4:59 PM, Matt Benson <gudnabr...@gmail.com> > wrote: > > On Fri, Jul 22, 2011 at 9:51 AM, Mark Struberg <strub...@yahoo.de> > wrote: > >> Hi Simo! > >> > >> Yea, taking the best ideas of both projects (meiyo > and xbean-finder) would definitlely be a big bonus. > >> But to be honest: I think we should rather stay on > the xbean-finder API. The reason is that it's already > heavily used in Geronimo, OpenEJB, OpenWebBeans and a few > other projects here at the ASF and abroad. So we should aim > to make the transition as easy as possible. Of course > tweaking the API to some degree is surely possible. > >> I also have to admit that I haven't heard of meiyo > before yesterday, so I don't know it's capabilities. > >> > > > > IMO the most interesting parts of meiyo to take away > are the > > filtering/callback APIs. I would think that this is > mostly part of > > (or at least an option of) the client API e.g. for the > single-scan > > feature, that we have to rewrite anyway. So I don't > think these goals > > are incompatible. > > > > Matt > > > >> In any case you are highly welcome to join forces > - any idea/opinion/help is welcome! > >> > >> LieGrue, > >> strub > >> > >> --- On Fri, 7/22/11, Simone Tripodi <simonetrip...@apache.org> > wrote: > >> > >>> From: Simone Tripodi <simonetrip...@apache.org> > >>> Subject: Re: [sandbox] class scanning + karma > requests > >>> To: "Commons Developers List" <dev@commons.apache.org> > >>> Date: Friday, July 22, 2011, 2:20 PM > >>> Hi all guys! > >>> That sounds really interesting!!! > >>> I think that bringing the new ideas in > existing [meiyo] > >>> APIs would > >>> allow us releasing a new component soon! > >>> Thanks in advance for your help and > interesting, looking > >>> forward to > >>> hear from you soon!!! > >>> Simo > >>> > >>> http://people.apache.org/~simonetripodi/ > >>> http://www.99soft.org/ > >>> > >>> > >>> > >>> On Fri, Jul 22, 2011 at 11:41 AM, Mark > Struberg <strub...@yahoo.de> > >>> wrote: > >>> > Hi! > >>> > > >>> > Jakob Korherr (apacheId jakobk) is also > interested and > >>> did some work in this area in MyFaces and OWB > already. > >>> > > >>> > There are 2 main parts in this project > >>> > > >>> > a.) A classpath scanner which does _not_ > use > >>> Class.getDeclaredXxx etc, since this allocates > memory in the > >>> ClassLoader which cannot get freed up later. > In a mid sized > >>> project this leads to getting 100MB of > PermGenSpace easily! > >>> This is what Davids xbean-finder fixes already > by just > >>> scanning the structure from the bytecode > directly. > >>> > > >>> > b.) Lots of EE apps need to scan the > classpath for > >>> annotations (e.g. MyFaces, OpenWebBeans, > Tomcat, OpenEJB, > >>> etc). So this part is done redundantly a few > times when > >>> starting the server. I hacked a quick API + > SPI to do all > >>> this in one go. The trick is to introduce a > register > >>> mechanism where classscan-clients can register > their needs > >>> before the scan gets performed. > >>> > > >>> > > >>> > We like to do this at commons because > it's really > >>> decoupled from all the single projects and > could be useful > >>> for a lot more projects which added some kind > of annotation > >>> processing lately. > >>> > > >>> > LieGrue, > >>> > strub > >>> > > >>> > --- On Fri, 7/22/11, Matt Benson <gudnabr...@gmail.com> > >>> wrote: > >>> > > >>> >> From: Matt Benson <gudnabr...@gmail.com> > >>> >> Subject: [sandbox] class scanning + > karma > >>> requests > >>> >> To: dev@commons.apache.org > >>> >> Cc: dblev...@apache.org, > >>> "Gerhard Petracek" <gerhard.petra...@gmail.com> > >>> >> Date: Friday, July 22, 2011, 4:30 AM > >>> >> First, Simo added [meiyo] to the > >>> >> sandbox. Now, some of the guys > from > >>> >> the various JEE-related communities > have expressed > >>> interest > >>> >> in working > >>> >> with class scanning here at > Commons. What we > >>> would > >>> >> propose to do is > >>> >> start with the code of Geronimo's > xbean-finder, > >>> which scans > >>> >> classes by > >>> >> reading bytecode to populate > meta-structures, > >>> thereby > >>> >> sparing permgen > >>> >> space whenever possible. We plan to > carefully > >>> prune > >>> >> and polish that > >>> >> code, pull in the best ideas from > [meiyo] (Simo > >>> and/or any > >>> >> of the rest > >>> >> of you Commons developers are of > course welcome > >>> to > >>> >> participate as > >>> >> always!), and add a single-scan SPI > strategy to > >>> allow the > >>> >> majority of > >>> >> consumers to share the impact of > scanning. For > >>> my own > >>> >> part, I hope to > >>> >> be able to contribute such that the > final API can > >>> >> accommodate most if > >>> >> not all conceivable use-cases for > classpath > >>> scanning, while > >>> >> not > >>> >> becoming too unwieldy. We'd like to > get started > >>> ASAP > >>> >> (and obviously > >>> >> nothing stops me from going ahead and > taking the > >>> first > >>> >> steps). I > >>> >> would also request our new chair > grant sandbox > >>> karma to: > >>> >> > >>> >> struberg (Mark Struberg) > >>> >> dblevins (David Blevins) > >>> >> gpetracek (Gerhard Petracek} > >>> >> > >>> >> Thanks, > >>> >> Matt > >>> >> > >>> >> > >>> > --------------------------------------------------------------------- > >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> >> For additional commands, e-mail: dev-h...@commons.apache.org > >>> >> > >>> >> > >>> > > >>> > > >>> > --------------------------------------------------------------------- > >>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> > For additional commands, e-mail: dev-h...@commons.apache.org > >>> > > >>> > > >>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
