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
