@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/ >> >>>>>> >> >>>>> >> >>> >> > >> > >
