hi!!! :) ok that sounds reasonable - and proves my lack of knowledge of EJB field (I'm not a JEE guy) :P
@Charles: I think that there is no measure for "too much consuming time" - I personally prefer adding overhead on compile phase rather than application runtime best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Apr 11, 2012 at 6:35 PM, James Carman <ja...@carmanconsulting.com> wrote: > The problem is that they might not have that luxury (using APT). The > specification (in the case of EJBs) says that classpath scanning must > be supported. > > On Wed, Apr 11, 2012 at 12:13 PM, Honton, Charles > <charles_hon...@intuit.com> wrote: >> Simo, >> >> How much time is too long? One minute? One second? Ten seconds? >> >> Thanks, >> chas >> >> -----Original Message----- >> From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf >> Of Simone Tripodi >> Sent: Wednesday, April 11, 2012 12:17 AM >> To: Commons Developers List >> Subject: Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for >> class path scanning / class metadata >> >> Same here, as main Meiyo contributor I'm of course interested, but no >> available cycles ATM, hopefully during the weekend :( >> >> Anyway, just to speak about it, I am changing my mind about classpath >> scanning, that - even only when bootstrapping, of course - is a time >> consuming operation. >> I'd invite you on thinking about an AnnotationProcessor that at >> compile-time generates the SPI META-INF/services files for >> @EJB/@Entity annotated classes - bootstrap would be of course faster! >> >> all the best, have a nice day! >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Tue, Apr 10, 2012 at 12:20 AM, James Carman >> <ja...@carmanconsulting.com> wrote: >>> I am interested. I do want to keep it as simple as possible to set up >>> and retrieve the information. I haven't had a chance to take a look >>> at your stuff, yet, though. Perhaps I can get a few cycles this week. >>> >>> On Mon, Apr 9, 2012 at 5:29 PM, Honton, Charles >>> <charles_hon...@intuit.com> wrote: >>>> There's been sporadic talk on this newsgroup since September 2010 about >>>> providing a commons component which can scan a classpath and provide >>>> metadata about the classes. I have a clean (license-wsie) concrete >>>> interface and implementation to share. This code will support the >>>> following use cases: >>>> >>>> 1. An ioc container used during unit testing that replaces the full-blown >>>> EJB container. The ioc container will auto-stitch the @Stateless unit >>>> under test with default @EJB implementations available from the classpath. >>>> The container allows replacement of default implementations with specific >>>> mocks. Framework needs to find @EJB interfaces and implementations >>>> available from jars in classpath. >>>> >>>> 2. Augment a code container to implement a domain event pub/sub framework. >>>> Auto-stitch the subscribers that want specific events to the publication >>>> of events. Framework needs to find implementations available to ear. >>>> >>>> 3. A JPA implementation must find all classes marked with @Entity within >>>> the same jar that contains a META-INF/persistence.xml file. >>>> >>>> Anyone still interested in supporting classpath / introspection features? >>>> >>>> Implementation available for download from >>>> <https://github.com/chonton/meiyo-sandbox> >>>> http://github.com/chonton/meiyo-sandbox >>>> >>>> Reports viewable at http://chonton.github.com/meiyo-sandbox/ >>>> >>>> Regards, >>>> chas >>>> >>>> --------------------------------------------------------------------- >>>> 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
