Ok, you are right, the name is wrong. It should rather be name 'CdiLifecycle' (or similar) rather than 'bootstrap'.
The problem is that bootstrapping without having control over the contexts makes no sense in SE applications. And having only control over the contexts without being able to actually start the container makes no sense neither. The big question for me is how to start control custom 3rd party contexts. 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/ >>>>>> >>>>> >>> >
