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.
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
