I had a quick chat with Gerhard and he is right that we only need the Context control for container-provided scopes.
For all other 3rd-party scopes we know which one we need/use anyway. So we can just invoke them from directly from the SE application without loosing any portability! But it's really important for the container built-in scopes! LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Thursday, February 16, 2012 10:28 AM > Subject: Re: [DISCUSS] bootstrap api > > 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/ >>>>>>> >>>>>> >>>> >> >
