+1 to Romain I'd like to see something like this for a 1.0 release. It would be a real game changer.
On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > I'd release 0.6 before having it, it will surely create discussion > once we'll get something and it is easy to do something totally > brokenn in particular when we'll want to get something clever in a web > context > > btw we shouldn't do it without pivotal IMO > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014/1/22 Jason Porter <lightguard...@gmail.com>: >> Do we just want to take what we had in Seam 3 and move it over? >> >> >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < >> gerhard.petra...@gmail.com> wrote: >> >>> hi jason, >>> >>> the bridge doesn't introduce an api and the spi just provides a simple >>> contract for starting the container as well as a bean-filter. >>> -> if needed, we could improve the implementation at any time. >>> imo we should add it before the release of v0.6 (since a lot of users >>> requested such a bridge). >>> >>> regards, >>> gerhard >>> >>> >>> >>> 2014/1/22 Jason Porter <lightguard...@gmail.com> >>> >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we >>> > can get some of there help as well to create a really good integration. >>> > >>> > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < >>> > gerhard.petra...@gmail.com> wrote: >>> > >>> >> hi @ all, >>> >> >>> >> i would like to continue with this discussion. >>> >> >>> >> [1] describes a two-way bridge which is already based on deltaspike. >>> >> it offers a simple spi which allows more advanced add-ons like it is >>> >> mentioned in [2]. >>> >> >>> >> regards, >>> >> gerhard >>> >> >>> >> [1] >>> >> >>> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html >>> >> >>> >> >>> >> >>> >> 2013/2/19 Matt Benson <gudnabr...@gmail.com> >>> >> >>> >>> Okay, I spent some time with Sam on IRC hashing this out. Assuming >>> that >>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for >>> deltaspike, >>> >>> his view is that it's not terribly important who does the initial code >>> >>> import, though it would be best for a so-authorized Red Hatter to be >>> the >>> >>> one to change the file headers. I will be out of pocket for the rest >>> of >>> >>> the week beyond today, so if you, Marius, are able to work on the >>> import >>> >>> end of this week/early next then that's in any event as soon as I would >>> >>> have been able to get to it anyway. Otherwise, anyone can do that, >>> with >>> >>> someone still employed by RH finally applying the change that modifies >>> >>> the >>> >>> headers--which, I suppose, could be prepared by anyone else and simply >>> >>> shared among our private git repos. >>> >>> >>> >>> Matt >>> >>> >>> >>> >>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < >>> >>> marius.bogoev...@gmail.com> wrote: >>> >>> >>> >>> > I still am a participant on this thread, but doing more reading than >>> >>> > writing as of late :) >>> >>> > >>> >>> > So, yes, I've been strapped for time with the job and the transition, >>> >>> but >>> >>> > I'd be happy to help out with this at the end of the week or early >>> >>> next. >>> >>> > >>> >>> > With my CLA on file, and the code being granted already, I'm not sure >>> >>> what >>> >>> > else needs to be done. I'm happy for the code to live in DeltaSpike, >>> >>> fwiw. >>> >>> > >>> >>> > On 2013-02-18, at 6:50 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>> >>> > >>> >>> > > Seems Marius's prior participation on this thread was via a gmail >>> >>> > address. >>> >>> > > With him no longer at Red Hat we definitely want to make sure we >>> >>> take the >>> >>> > > necessary precautions wrt IP. >>> >>> > > >>> >>> > > Matt >>> >>> > > >>> >>> > > >>> >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter < >>> >>> lightguard...@gmail.com >>> >>> > >wrote: >>> >>> > > >>> >>> > >> I'm pretty sure we've granted Seam Spring to Apache. I'll need to >>> >>> check >>> >>> > to >>> >>> > >> see if Marius has subscribed to this list on a personal email as >>> he >>> >>> has >>> >>> > >> embarked on a new adventure outside of Red Hat. >>> >>> > >> >>> >>> > >> >>> >>> > >> On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson < >>> gudnabr...@gmail.com> >>> >>> > wrote: >>> >>> > >> >>> >>> > >>> Let me refine my plan to say that it would be *best* if Marius >>> >>> does the >>> >>> > >>> commit since AIUI this is mostly code he personally authored, but >>> >>> as >>> >>> > long >>> >>> > >>> as RH intends for Seam-Spring to be donated to Apache deltaspike, >>> >>> > probably >>> >>> > >>> no irreparable *harm* would be caused by another Red Hatter >>> >>> pulling the >>> >>> > >>> trigger. >>> >>> > >>> >>> >>> > >>> Matt >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson < >>> gudnabr...@gmail.com >>> >>> > >>> >>> > >>> wrote: >>> >>> > >>> >>> >>> > >>>> I think this received enough +1 votes (I'll add mine now) to >>> >>> proceed. >>> >>> > >>> If >>> >>> > >>>> a Red Hatter (Marius?) would do the simplest repackaging >>> possible >>> >>> and >>> >>> > >>>> commit that then others could join in the quest to modularize >>> the >>> >>> hell >>> >>> > >>> out >>> >>> > >>>> of it. :) Presumably we'd do this on a branch until considered >>> >>> > "baked" >>> >>> > >>>> enough to merge to master. >>> >>> > >>>> >>> >>> > >>>> Let's go! >>> >>> > >>>> >>> >>> > >>>> Matt >>> >>> > >>>> >>> >>> > >>>> >>> >>> > >>>> On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg < >>> >>> > >>>> arne.limb...@openknowledge.de> wrote: >>> >>> > >>>> >>> >>> > >>>>> Hi, >>> >>> > >>>>> >>> >>> > >>>>> Some ideas from my side, too ([1] and [2]). Unfortunately it is >>> >>> in >>> >>> > >>> german. >>> >>> > >>>>> But everyone of you can read the code. We used an advanced >>> >>> version of >>> >>> > >>> that >>> >>> > >>>>> code to build a Spring-CDI-Bridge in a large project. >>> >>> Unfortunately >>> >>> > >>>>> meanwhile the project is completely migrated to CDI and the >>> code >>> >>> is >>> >>> > >>> lost >>> >>> > >>>>> in subversion. Will see, if I find the final version and can >>> >>> donate >>> >>> > it. >>> >>> > >>>>> >>> >>> > >>>>> Cheers, >>> >>> > >>>>> Arne >>> >>> > >>>>> >>> >>> > >>>>> [1] >>> >>> > >>>>> >>> >>> > >>>>> >>> >>> > >>> >>> >>> > >>> >>> >>> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe >>> >>> > >>>>> r-eine-cdi-extension-erster-teil.html< >>> >>> > >>> >>> >>> > >>> >>> >>> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html >>> >>> > >>>> >>> >>> > >>>>> [2] >>> >>> > >>>>> >>> >>> > >>>>> >>> >>> > >>> >>> >>> > >>> >>> >>> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe >>> >>> > >>>>> r-eine-cdi-extension-zweiter-teil.html< >>> >>> > >>> >>> >>> > >>> >>> >>> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html >>> >>> > >>>> >>> >>> > >>> >>> >>> > >>>>> >>> >>> > >>>>> >>> >>> > >>>>> Am 15.10.12 17:16 schrieb "Jason Porter" unter < >>> >>> > >>> lightguard...@gmail.com>: >>> >>> > >>>>> >>> >>> > >>>>>> You have my +1 Marius. If we can rouse the CDISource guys >>> >>> (mostly >>> >>> > >>> Rick) >>> >>> > >>>>>> they may have some ideas as well. >>> >>> > >>>>>> >>> >>> > >>>>>> On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand < >>> >>> > >>>>>> anto...@sabot-durand.net> wrote: >>> >>> > >>>>>> >>> >>> > >>>>>>> +1 it would definitively improve Java EE and CDI adoption. >>> >>> > >>>>>>> >>> >>> > >>>>>>> Antoine SABOT-DURAND >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau < >>> >>> rmannibu...@gmail.com >>> >>> > > >>> >>> > >>> a >>> >>> > >>>>>>> écrit : >>> >>> > >>>>>>> >>> >>> > >>>>>>>> +1 (since DS manages spring context lifecycle) >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> *Romain Manni-Bucau* >>> >>> > >>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> >>> > >>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*< >>> >>> > >>>>>>> http://rmannibucau.wordpress.com/> >>> >>> > >>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> >>> > >>>>>>>> *Github: https://github.com/rmannibucau* >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> 2012/10/15 Mark Struberg <strub...@yahoo.de> >>> >>> > >>>>>>>> >>> >>> > >>>>>>>>> great stuff, +1! >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> Just to help me understand a bit better. This module will >>> >>> cover a >>> >>> > >>>>>>>>> Spring-CDI bridge, so you boot Spring and a CDI container >>> and >>> >>> > >>> route >>> >>> > >>>>>>> the >>> >>> > >>>>>>>>> beans between both of them, right? >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> Just for getting the whole picture: Another way is to just >>> >>> > >>> interpret >>> >>> > >>>>>>> the >>> >>> > >>>>>>>>> spring beans.xml and serve it all purely with CDI. Of >>> course >>> >>> this >>> >>> > >>>>>>> will >>> >>> > >>>>>>>>> pretty surely not be possible to implement 100% compatible >>> >>> thus >>> >>> > >>> I'm >>> >>> > >>>>>>> not >>> >>> > >>>>>>>>> sure if it's worth implementing at all. >>> >>> > >>>>>>>>> I guess this is _not_ covered in your proposal, right? Imo >>> >>> this >>> >>> > >>> is >>> >>> > >>>>>>>>> perfectly fine, I just mention it for clarity. >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> LieGrue, >>> >>> > >>>>>>>>> strub >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> ----- Original Message ----- >>> >>> > >>>>>>>>>> From: Marius Bogoevici <marius.bogoev...@gmail.com> >>> >>> > >>>>>>>>>> To: deltaspike-...@incubator.apache.org >>> >>> > >>>>>>>>>> Cc: >>> >>> > >>>>>>>>>> Sent: Monday, October 15, 2012 8:33 AM >>> >>> > >>>>>>>>>> Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Hello all, >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Please check [1] before you answer. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> I'd like to propose the addition of a new module for >>> >>> integrating >>> >>> > >>>>>>> Spring >>> >>> > >>>>>>>>> with >>> >>> > >>>>>>>>>> CDI. We have discussed this on the e-mail list but let me >>> >>> > >>> provide a >>> >>> > >>>>>>> quick >>> >>> > >>>>>>>>>> rationale for it. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> - it eases adoption of CDI and, by extension, Java EE, in >>> >>> > >>>>>>> environments >>> >>> > >>>>>>>>> with a >>> >>> > >>>>>>>>>> significant existing Spring codebase; >>> >>> > >>>>>>>>>> - it provides a general solution for Spring/Java EE >>> >>> integration; >>> >>> > >>>>>>>>>> - it provides users with more options in choosing the best >>> >>> > >>>>>>> components >>> >>> > >>>>>>>>> for their >>> >>> > >>>>>>>>>> application, knowing that they are not locked in either of >>> >>> the >>> >>> > >>>>>>> paradigms >>> >>> > >>>>>>>>> (e.g. a >>> >>> > >>>>>>>>>> user can integrate a project with a strong CDI-based >>> >>> programming >>> >>> > >>>>> API >>> >>> > >>>>>>> with >>> >>> > >>>>>>>>>> something like Spring Batch or Spring Integration); >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Features (proposed) >>> >>> > >>>>>>>>>> ----------------- >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> a) bidirectional injection of beans (Spring into CDI and >>> >>> > >>>>>>> vice-versa); >>> >>> > >>>>>>>>>> b) bridging EntityTransaction support between DeltaSpike >>> and >>> >>> > >>>>> Spring; >>> >>> > >>>>>>>>>> c) integrating the CDI event model with Spring (the best >>> >>> > >>> approach >>> >>> > >>>>>>> in my >>> >>> > >>>>>>>>> opinion >>> >>> > >>>>>>>>>> being Spring Integraton rather than the core) >>> >>> > >>>>>>>>>> d) integration with other Spring portfolio projects >>> wherever >>> >>> > >>>>>>> possible; >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> For version 0.4 a minimal goal would be a), followed by b) >>> >>> if >>> >>> > >>>>>>> possible. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> General approach (covers a)) >>> >>> > >>>>>>>>>> ================= >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> For 0.4. my intent, by and large, is to follow the >>> >>> approaches of >>> >>> > >>>>> the >>> >>> > >>>>>>>>> Seam 3 >>> >>> > >>>>>>>>>> Spring module (including a code migration), making >>> >>> improvements >>> >>> > >>> on >>> >>> > >>>>>>> its >>> >>> > >>>>>>>>> design >>> >>> > >>>>>>>>>> wherever possible. I intend to create individual JIRAs >>> for a >>> >>> > >>> more >>> >>> > >>>>>>>>> detailed >>> >>> > >>>>>>>>>> discussion, but here's the outline: >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> The general principle is that each side (Spring, CDI) >>> >>> should not >>> >>> > >>>>>>> know >>> >>> > >>>>>>>>> about the >>> >>> > >>>>>>>>>> existence of the other. Spring beans should be used as CDI >>> >>> beans >>> >>> > >>>>>>>>> transparently >>> >>> > >>>>>>>>>> and vice-versa. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> So where do beans come from? >>> >>> > >>>>>>>>>> ------------------------ >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Spring beans are exposed through a /resource producer >>> >>> > >>> pattern//./ >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> @Produces @SpringBean Foo bar; >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Will produce a CDI bean of the type Foo acquired from the >>> >>> Spring >>> >>> > >>>>>>> context >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Details: >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>> >>> >>> > >>> >>> >>> > >>> >>> >>> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us >>> >>> > >>>>>>> age.html#d0e92 >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> What Spring context? >>> >>> > >>>>>>>>>> ------------------ >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> For flexibility reasons, we do not assume where the Spring >>> >>> > >>> context >>> >>> > >>>>>>> is >>> >>> > >>>>>>>>> coming >>> >>> > >>>>>>>>>> from. Therefore, we allow different mechanisms for >>> >>> accessing a >>> >>> > >>>>>>> Spring >>> >>> > >>>>>>>>> context. >>> >>> > >>>>>>>>>> In fact, multiple contexts can be used for import. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> a) parent web context [3] >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> @Produces @Web @SpringContext ApplicationContext >>> >>> > >>>>> applicationContext; >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> b) Configuration-file based application context [4] >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> @Produces >>> >>> > >>> @Configuration("classpath*:META-INF/spring/context.xml") >>> >>> > >>>>>>>>>> @SpringContext ApplicationContext applicationContext; >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> (TBD: issues like auto-import and auto-vetoing, as well as >>> >>> > >>> sensible >>> >>> > >>>>>>>>> defaults) >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> The Spring bean producer can reference a specific context >>> >>> (see >>> >>> > >>>>>>>>> documentation for >>> >>> > >>>>>>>>>> details) >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Note: When we get to the JIRAs we can consider alternative >>> >>> > >>> designs >>> >>> > >>>>> - >>> >>> > >>>>>>> e.g. >>> >>> > >>>>>>>>>> grouping all producers for a particular context in a >>> single >>> >>> bean >>> >>> > >>>>> and >>> >>> > >>>>>>>>> making that >>> >>> > >>>>>>>>>> bean the Spring context reference marker. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Note #2: In regards to the CDISource implementation: I am >>> >>> happy >>> >>> > >>>>> with >>> >>> > >>>>>>>>> reusing >>> >>> > >>>>>>>>>> some of the stuff there, but I have a hard time looking at >>> >>> the >>> >>> > >>>>> code, >>> >>> > >>>>>>> it's >>> >>> > >>>>>>>>>> never been released (as in a Maven release), lacks >>> >>> > >>> documentation, >>> >>> > >>>>>>> and >>> >>> > >>>>>>>>> reverse >>> >>> > >>>>>>>>>> engineering is hard. So if someone that is familiar with >>> the >>> >>> > >>> code >>> >>> > >>>>>>> and >>> >>> > >>>>>>>>> finds >>> >>> > >>>>>>>>>> something particularly apt for reuse, and it's also OK >>> from >>> >>> an >>> >>> > >>>>>>> Apache >>> >>> > >>>>>>>>> code >>> >>> > >>>>>>>>>> policy point of view, we should incorporate anything that >>> >>> helps. >>> >>> > >>>>>>> What >>> >>> > >>>>>>> I >>> >>> > >>>>>>>>> am not >>> >>> > >>>>>>>>>> particularly happy with is the approach of annotating CDI >>> >>> > >>> injection >>> >>> > >>>>>>>>> points with >>> >>> > >>>>>>>>>> the @Spring marker, which I believe violates separation of >>> >>> > >>> concerns >>> >>> > >>>>>>> - I >>> >>> > >>>>>>>>> consider >>> >>> > >>>>>>>>>> production or auto-registration a better approach (CDI >>> >>> targets >>> >>> > >>>>>>> should >>> >>> > >>>>>>>>> not know >>> >>> > >>>>>>>>>> about the provenience of the bean). >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> CDI into Spring integration [5] >>> >>> > >>>>>>>>>> =================== >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Conversely, CDI beans can be injected into Spring >>> >>> applications. >>> >>> > >>> To >>> >>> > >>>>>>> that >>> >>> > >>>>>>>>> end, we >>> >>> > >>>>>>>>>> will provide a namespace (and possibly a JavaConfig >>> >>> > >>> configuration >>> >>> > >>>>>>>>> mechanism) >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Structure >>> >>> > >>>>>>>>>> ====== >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> The integration can be split into multiple modules, one >>> for >>> >>> each >>> >>> > >>>>>>>>> features above. >>> >>> > >>>>>>>>>> a) can be split into two different modules too. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Roadmap >>> >>> > >>>>>>>>>> ====== >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> I think that the first vote would be for the inclusion of >>> >>> the >>> >>> > >>>>> module >>> >>> > >>>>>>> (or >>> >>> > >>>>>>>>>> modules), followed by discussion of the JIRAs. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> [1] http://markmail.org/message/7yefspfuvtz4jvmp >>> >>> > >>>>>>>>>> [2] >>> >>> > >>>>> >>> https://cwiki.apache.org/DeltaSpike/spring-cdi-integration.html >>> >>> > >>>>>>>>>> [3] >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>> >>> >>> > >>> >>> >>> > >>> >>> >>> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us >>> >>> > >>>>>>> age.html#d0e92 >>> >>> > >>>>>>>>>> [4] >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>> >>> >>> > >>> >>> >>> > >>> >>> >>> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us >>> >>> > >>>>>>> age.html#d0e92 >>> >>> > >>>>>>>>>> [5] >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>> >>> >>> > >>> >>> >>> > >>> >>> >>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManag >>> >>> > >>>>>>> er.html >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>> >>> >>> > >>>>>> >>> >>> > >>>>>> -- >>> >>> > >>>>>> Jason Porter >>> >>> > >>>>>> http://lightguard-jp.blogspot.com >>> >>> > >>>>>> http://twitter.com/lightguardjp >>> >>> > >>>>>> >>> >>> > >>>>>> Software Engineer >>> >>> > >>>>>> Open Source Advocate >>> >>> > >>>>>> Author of Seam Catch - Next Generation Java Exception Handling >>> >>> > >>>>>> >>> >>> > >>>>>> PGP key id: 926CCFF5 >>> >>> > >>>>>> PGP key available at: keyserver.net, pgp.mit.edu >>> >>> > >>>>> >>> >>> > >>>>> >>> >>> > >>>> >>> >>> > >>> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> -- >>> >>> > >> Jason Porter >>> >>> > >> http://en.gravatar.com/lightguardjp >>> >>> > >> >>> >>> > >>> >>> > >>> >>> >>> >> >>> >> >>> > >>> > >>> > -- >>> > Jason Porter >>> > http://en.gravatar.com/lightguardjp >>> > >>> >> >> >> >> -- >> Jason Porter >> http://en.gravatar.com/lightguardjp
