short addition: artifactId: deltaspike-cdi-se groupId something like: org.apache.deltaspike.jse-support
regards, gerhard 2012/2/19 Gerhard Petracek <[email protected]> > +1 and CdiContainerLoader instead of ContainerControlLoader > > regards, > gerhard > > > > > 2012/2/19 Mark Struberg <[email protected]> > >> oki, what about: >> >> project module name: cdise >> package: cdise >> Interface: CdiContainer >> >> ? >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >> > From: Mark Struberg <[email protected]> >> > To: "[email protected]" < >> [email protected]> >> > Cc: >> > Sent: Sunday, February 19, 2012 7:06 PM >> > Subject: Re: [DISCUSS] bootstrap api >> > >> > please feel free to propose a better name. >> > If we agree on a new one, then I'm happy to rename it. >> > >> > LieGrue, >> > strub >> > >> > >> > >> > ----- Original Message ----- >> >> From: Gerhard Petracek <[email protected]> >> >> To: [email protected] >> >> Cc: >> >> Sent: Sunday, February 19, 2012 4:03 PM >> >> Subject: Re: [DISCUSS] bootstrap api >> >> >> >> @module name: >> >> i agree with pete! here is my -0.5 for "container" in the name. >> >> imo we need a name which makes clear that this module is just needed >> with >> >> java-se. >> >> >> >> furthermore, we should use unified names for the test modules. >> >> >> >> regards, >> >> gerhard >> >> >> >> >> >> >> >> 2012/2/18 Gerhard Petracek <[email protected]> >> >> >> >>> +1 >> >>> >> >>> regards, >> >>> gerhard >> >>> >> >>> >> >>> >> >>> >> >>> 2012/2/18 Mark Struberg <[email protected]> >> >>> >> >>>> Hi folks! >> >>>> >> >>>> I've now drafted a first version of the API >> >>>> >> >>>> >> >>>> >> >> >> > >> https://github.com/struberg/incubator-deltaspike/blob/containerctrl/deltaspike/containerctrl/api/src/main/java/org/apache/deltaspike/containerctrl/api/ContainerControl.java >> >>>> >> >>>> wdyt? >> >>>> >> >>>> I think it's now clear that we only need this for built-in >> > scopes, >> >> but >> >>>> it's really nice to provide that way. >> >>>> Pete, I don't get the argument with CDI<T> because it >> >> doesn't offer >> >>>> anything close to the functionality of the ContainerControl. >> >>>> >> >>>> LieGrue, >> >>>> strub >> >>>> >> >>>> >> >>>> >> >>>> ----- Original Message ----- >> >>>> > From: Pete Muir <[email protected]> >> >>>> > To: [email protected]; Mark Struberg < >> >>>> [email protected]> >> >>>> > Cc: >> >>>> > Sent: Wednesday, February 15, 2012 9:31 PM >> >>>> > Subject: Re: [DISCUSS] bootstrap api >> >>>> > >> >>>> > Aha, so this is "mixing" bootstrap and context >> > lifecycle >> >> management? >> >>>> > If so, I would prefer we keep these as two separate APIs. I >> > can >> >> make a >> >>>> proposal >> >>>> > for a context lifecycle management api based on what we have >> > in >> >> Weld. >> >>>> > >> >>>> > On 15 Feb 2012, at 17:17, Mark Struberg wrote: >> >>>> > >> >>>> >> Hi Pete! >> >>>> >> >> >>>> >> fluent api is fine for me. >> >>>> >> >> >>>> >> The reason why the context control is so fine granular >> > is >> >> that you >> >>>> > don't have any well defined extension points in an SE >> > app. >> >> Thus the >> >>>> > application must perform those steps itself. >> >>>> >> >> >>>> >> >> >>>> >> Imagine a Swing App. >> >>>> >> A Request could be a user interaction. >> >>>> >> >> >>>> >> A Conversation could start when a multi-page dialogue >> > gets >> >> opened and >> >>>> ends >> >>>> > when it will finally be stored. >> >>>> >> etc. >> >>>> >> Of course for custom scopes this needs to be refined or >> > the >> >> Extension >> >>>> > providing this scope must allow us to control this. >> >>>> >> >> >>>> >> LieGrue, >> >>>> >> strub >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> ----- Original Message ----- >> >>>> >>> From: Pete Muir <[email protected]> >> >>>> >>> To: [email protected]; Mark >> > Struberg >> >>>> > <[email protected]> >> >>>> >>> Cc: >> >>>> >>> Sent: Wednesday, February 15, 2012 4:59 PM >> >>>> >>> Subject: Re: [DISCUSS] bootstrap api >> >>>> >>> >> >>>> >>> My first thoughts: >> >>>> >>> >> >>>> >>> * the API should be fluent - always return an >> > instance of >> >> the >> >>>> bootstrap >> >>>> > API >> >>>> >>> class >> >>>> >>> * I would prefer to avoid the use of the word >> > container, >> >> on the whole >> >>>> > the spec >> >>>> >>> avoids that term as it's overloaded >> >>>> >>> * I'm unsure of why you want to start the >> > contexts >> >> with such >> >>>> > granularity, >> >>>> >>> and want to understand the use cases better. I'm >> > not >> >> really sure >> >>>> > why you >> >>>> >>> want to control this outside the main start/stop >> >> methods... >> >>>> >>> * I would prefer start/stop to boot/shutdown - >> > again, >> >> slightly less >> >>>> > meaning >> >>>> >>> attached to the terms which might be confusing >> >>>> >>> * Make sure that this class has the same methods as >> > the >> >> CDI class >> >>>> from >> >>>> > CDI 1.1, >> >>>> >>> so that we don't make people change their API >> > too >> >> much >> >>>> >>> >> >>>> >>> On 10 Feb 2012, at 17:35, Mark Struberg wrote: >> >>>> >>> >> >>>> >>>> Hi! >> >>>> >>>> >> >>>> >>>> Thats perfectly fine. Keep the ideas rolling ;) >> >>>> >>>> >> >>>> >>>> The original API was intended for doing a quick >> > cdi >> >> boot for unit >> >>>> > testing, >> >>>> >>> thus it might miss some features. >> >>>> >>>> >> >>>> >>>> LieGrue, >> >>>> >>>> strub >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> ----- Original Message ----- >> >>>> >>>>> From: Pete Muir <[email protected]> >> >>>> >>>>> To: [email protected]; >> > Mark >> >> Struberg >> >>>> >>> <[email protected]> >> >>>> >>>>> Cc: >> >>>> >>>>> Sent: Friday, February 10, 2012 12:11 PM >> >>>> >>>>> Subject: Re: [DISCUSS] bootstrap api >> >>>> >>>>> >> >>>> >>>>> +1 to the idea but I would want to discuss >> > the >> >> API in quite a >> >>>> > lot of >> >>>> >>> detail. >> >>>> >>>>> >> >>>> >>>>> On 9 Feb 2012, at 10:13, Mark Struberg >> > wrote: >> >>>> >>>>> >> >>>> >>>>>> Hi! >> >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> I developed an API to bootstrap and >> > control >> >> CDI containers >> >>>> > from >> >>>> >>> within a SE >> >>>> >>>>> application [1]. >> >>>> >>>>>> This was originally developed to make >> >> OpenWebBeans SE >> >>>> > applications >> >>>> >>> easily >> >>>> >>>>> testable, but it also can be used for SE >> >> applications in >> >>>> > general! >> >>>> >>>>>> >> >>>> >>>>>> There is already an implementation for >> >> OpenWebBeans [2] and >> >>>> > it >> >>>> >>> would be >> >>>> >>>>> really easy to also provide the same for >> > various >> >> Weld versions. >> >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> wdyt? Could be nice to import this as >> >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> core/bootstrap/api >> >>>> >>>>>> core/bootstrap/owb >> >>>> >>>>>> and add a new >> >>>> >>>>>> core/bootstrap/weld >> >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> LieGrue, >> >>>> >>>>>> strub >> >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> [1] >> >>>> >>>>> >> >>>> >>> >> >>>> > >> >>>> >> >> >> > >> https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-test/cditest/src/main/java/org/apache/webbeans/cditest/ >> >>>> >>>>>> [2] >> >>>> >>>>> >> >>>> >>> >> >>>> > >> >>>> >> >> >> > >> https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-test/cditest-owb/ >> >>>> >>>>>> >> >>>> >>>>> >> >>>> >>> >> >>>> > >> >>>> >> >>> >> >>> >> >> >> > >> > >
