Sorry ;-) (A).
On 19 Mar 2012, at 14:52, Mark Struberg wrote: >> Personally, I think this is a safe API to go with for no > And which of the 2 options did 'this' stand for? :) > > > A.) startRequestContext + startSessionContext + ... > > B.) startContext(scopeAnnotation) > > > ? > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Pete Muir <pm...@redhat.com> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg <strub...@yahoo.de> >> Cc: >> Sent: Monday, March 19, 2012 3:41 PM >> Subject: Re: [DISCUSS] start()/boot() vs stop()/shutdown() >> >> Personally, I think this is a safe API to go with for now, and we can always >> explore a simplified API down the line... >> >> On 19 Mar 2012, at 14:30, Mark Struberg wrote: >> >>> Well, the separate start/stop for the contexts is exactly what we did have >> in owb-test [1]. >>> I changed this to a more general approach as I felt it is more extensible. >> If we would introduce a new scope in CDI-x then we would not need to change >> any >> API. But I'm completely ok with moving back to the more verbose but also way >> more well specified methods again. >>> >>> >>> LieGrue, >>> strub >>> >>> >>> [1] >> https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-test/cditest/src/main/java/org/apache/webbeans/cditest/CdiTestContainer.java >>> >>> >>> >>> ----- Original Message ----- >>>> From: Pete Muir <pm...@redhat.com> >>>> To: deltaspike-dev@incubator.apache.org >>>> Cc: >>>> Sent: Monday, March 19, 2012 3:24 PM >>>> Subject: Re: [DISCUSS] start()/boot() vs stop()/shutdown() >>>> >>>> You can't restart the application context in Weld. >>>> >>>> I'll have to think on what this means for the API you propose, but >> my first >>>> instinct is to say that we should offer any global start/stop context >> APIs at >>>> all, but require users to activate the ones they want explicitly. This >> is more >>>> code, but it seems to be the only portable and sane option. >>>> >>>> On 19 Mar 2012, at 14:08, Gerhard Petracek wrote: >>>> >>>>> hi mark, >>>>> >>>>> @testing request scoped entity-managers: >>>>> you still have #startContext and #stopContext >>>>> >>>>> i haven't tested if weld destroys the beans 100% correctly (the >> wrong >>>>> result of #isActive is the only issue i've seen with weld), but >> you get >>>> a >>>>> new application scoped bean after calling #stopContexts. >>>>> however, since a part of it is broken (or users have to use a >> workaround), >>>>> it doesn't make sense imo to provide such a >> "convenience" >>>> method which >>>>> doesn't work correctly (out-of-the-box). >>>>> >>>>> regards, >>>>> gerhard >>>>> >>>>> >>>>> >>>>> 2012/3/19 Mark Struberg <strub...@yahoo.de> >>>>> >>>>>> Starting/stopping contexts in tests is exactly one of the use >> cases I >>>> do a >>>>>> lot. Especially to close any @RequestScoped EntityManager. >>>>>> >>>>>> See also the blog post I wrote on the weekend: >>>>>> >>>>>> >>>> >> https://struberg.wordpress.com/2012/03/17/controlling-cdi-containers-in-se-and-ee/ >>>>>> >>>>>> >>>>>> There is only one little annoyance. Both Weld and OWB do not >> like it if >>>>>> the ApplicationContext gets stopped without restarting the CDI >>>> container. >>>>>> In Weld the ApplicationContext always reports isActive() true >> and in >>>> OWB >>>>>> (depending on the configured proxy) we cache resolved >> contextual >>>> instances >>>>>> of @ApplicationScoped beans directly in the >>>>>> ApplicationScopedBeanInterceptorHandler of their proxies. >>>>>> If you need to restart your ApplicationContext with OWB you >> would need >>>> to >>>>>> configure the NormalScopedBeanInterceptorHandler for >> @ApplicationScoped >>>>>> >>>>>> Just create a META-INF/openwebbeans/openwebbeans.properties and >> paste >>>> the >>>>>> following line into it: >>>>>> >>>>>> configuration.ordinal=101 >>>>>> >>>> >> org.apache.webbeans.proxy.mapping.javax.enterprise.context.ApplicationScoped=org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandlerThe >>>>>> syntax is: >>>>>> org.apache.webbeans.proxy.mapping.[the fully qualified name of >> the >>>> scope >>>>>> annotation]=[proxy method handler implementation] >>>>>> >>>>>> The default config can be found here: [1] >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> [1] >>>>>> >>>> >> https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-impl/src/main/resources/META-INF/openwebbeans/openwebbeans.properties >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: Pete Muir <pm...@redhat.com> >>>>>>> To: deltaspike-dev@incubator.apache.org >>>>>>> Cc: Mark Struberg <strub...@yahoo.de> >>>>>>> Sent: Monday, March 19, 2012 2:29 PM >>>>>>> Subject: Re: [DISCUSS] start()/boot() vs stop()/shutdown() >>>>>>> >>>>>>> What about if I wanted to stop the contexts and then start >> them >>>> again, >>>>>> without >>>>>>> restarting the container? This is definitely useful in >> tests! >>>>>>> >>>>>>> Or am I confused about terminology again? AFAIK We talk >> about >>>>>> starting/stopping >>>>>>> a session or request which refers to the session or request >> >>>> boundaries. >>>>>>> >>>>>>> On 19 Mar 2012, at 13:15, Gerhard Petracek wrote: >>>>>>> >>>>>>>> hi mark, >>>>>>>> >>>>>>>> if all supported containers stop the contexts during >> the >>>> shutdown >>>>>>>> (without #stopContexts) >and< we don't have >> enough >>>> use-cases for >>>>>>>> #startContexts, we don't need #startContexts and >>>> #stopContexts at all >>>>>>> (they >>>>>>>> are also just convenience methods). >>>>>>>> >>>>>>>> @comments in jira: >>>>>>>> as i see you added it to [1] and not to [2], however, >> if we >>>> remove >>>>>>>> something, we also have to check/update the >> documentation. >>>>>>>> >>>>>>>> -> we need a better workflow for the api-design. >>>>>>>> >>>>>>>> regards, >>>>>>>> gerhard >>>>>>>> >>>>>>>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-92 >>>>>>>> [2] >> https://issues.apache.org/jira/browse/DELTASPIKE-106 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2012/3/19 Mark Struberg <strub...@yahoo.de> >>>>>>>> >>>>>>>>> I think we do have this already as the containers >> do this >>>> internally >>>>>>>>> afaik. But you are right that we should add a test >> for it >>>> in the TCK! >>>>>>>>> >>>>>>>>> We could e.g. introduce a @RequestScoped bean with >> a >>>> @PreDestroy which >>>>>>>>> sets a static boolean properlyDestroyed; to true; >> and test >>>> for it >>>>>> after >>>>>>> the >>>>>>>>> container.shutdown(); >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: Gerhard Petracek >>>> <gerhard.petra...@gmail.com> >>>>>>>>>> To: deltaspike-dev@incubator.apache.org >>>>>>>>>> Cc: >>>>>>>>>> Sent: Monday, March 19, 2012 1:44 PM >>>>>>>>>> Subject: Re: [DISCUSS] start()/boot() vs >>>> stop()/shutdown() >>>>>>>>>> >>>>>>>>>> hi mark, >>>>>>>>>> >>>>>>>>>> 3 lines would mean that we agree on the merged >> shutdown >>>> and that >>>>>>> isn't >>>>>>>>> what >>>>>>>>>> we have right now. >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> gerhard >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2012/3/19 Pete Muir <pm...@redhat.com> >>>>>>>>>> >>>>>>>>>>> I'm strongly in favour of the slightly >> more >>>> verbose API >>>>>>> that Mark >>>>>>>>>> proposes >>>>>>>>>>> where contexts are started/stopped >> separately from >>>> booting the >>>>>>>>> container. >>>>>>>>>>> For me, this is a semantically different >> operation >>>> (starting >>>>>>> CDI is not >>>>>>>>>>> naturally associated with starting a >> session or a >>>> request). I >>>>>>> don't >>>>>>>>>> think >>>>>>>>>>> reducing 3 lines -> 2 lines is really >> worth the >>>> drop in >>>>>>> clarity it >>>>>>>>>> results >>>>>>>>>>> in. >>>>>>>>>>> >>>>>>>>>>> I do think that shutdown() should >> automatically >>>> stop any >>>>>>> contexts still >>>>>>>>>>> running. I realise this isn't symmetric >> >>>> however, which does >>>>>>> make me >>>>>>>>>> pause >>>>>>>>>>> for thought. >>>>>>>>>>> >>>>>>>>>>> So +1 to keeping the API as it is. >>>>>>>>>>> >>>>>>>>>>> On 19 Mar 2012, at 12:30, Mark Struberg >> wrote: >>>>>>>>>>> >>>>>>>>>>>>> that means you have to write 4 >> lines in >>>>> several< >>>>>>> (for sure >>>>>>>>>> not all) >>>>>>>>>>>>> cases, >>>>>>>>>>>>> but you can do the same with 2 >> lines (with >>>> the >>>>>>> convenience >>>>>>>>>> methods). >>>>>>>>>>>> >>>>>>>>>>>> nope its 3 lines vs 2 lines ;) >>>>>>>>>>>> >>>>>>>>>>>> boot(); >>>>>>>>>>>> startyourcontexts >>>>>>>>>>>> shutdown(); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Maybe we should comment and test that >> the >>>> container must >>>>>>> ensure that >>>>>>>>>> all >>>>>>>>>>> contexts get automatically stopped during a >> >>>> shutdown(). >>>>>>>>>>>> But that should serve sufficiently. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> at least we have to discuss it >> (instead of >>>> removing an >>>>>>> existing >>>>>>>>>> api >>>>>>>>>>>>> "silently"). >>>>>>>>>>>> >>>>>>>>>>>> I guess there is more discussion and >>>> argumentation why I >>>>>>> removed >>>>>>>>> those >>>>>>>>>>> methods in the JIRA ticket than for all the >> adding >>>> of those >>>>>>>>>> 'convenience' >>>>>>>>>>> methods in summary. Please look at the >>>> corresponding Jira >>>>>>> ticket. >>>>>>>>>>>> >>>>>>>>>>>> LieGrue, >>>>>>>>>>>> strub >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: Gerhard Petracek >>>>>>> <gerhard.petra...@gmail.com> >>>>>>>>>>>>> To: >> deltaspike-dev@incubator.apache.org >>>>>>>>>>>>> Cc: >>>>>>>>>>>>> Sent: Monday, March 19, 2012 1:12 >> PM >>>>>>>>>>>>> Subject: Re: [DISCUSS] >> start()/boot() vs >>>>>>> stop()/shutdown() >>>>>>>>>>>>> >>>>>>>>>>>>> hi mark, >>>>>>>>>>>>> >>>>>>>>>>>>> that means you have to write 4 >> lines in >>>>> several< >>>>>>> (for sure >>>>>>>>>> not all) >>>>>>>>>>>>> cases, >>>>>>>>>>>>> but you can do the same with 2 >> lines (with >>>> the >>>>>>> convenience >>>>>>>>>> methods). >>>>>>>>>>>>> if there was confusion about the >> previous >>>> convenience >>>>>>> methods (i >>>>>>>>>> can't >>>>>>>>>>> see >>>>>>>>>>>>> it in the archive), it's just a >> matter >>>> of >>>>>>> documentation (= one >>>>>>>>>> line of >>>>>>>>>>>>> javadoc). >>>>>>>>>>>>> at least we have to discuss it >> (instead of >>>> removing an >>>>>>> existing >>>>>>>>>> api >>>>>>>>>>>>> "silently"). >>>>>>>>>>>>> >>>>>>>>>>>>> if we can't agree on such >> convenience >>>> methods, we >>>>>>> have to >>>>>>>>>> merge the >>>>>>>>>>>>> shutdown logic. right now it's >> too >>>> error prone (see >>>>>>> [1]). >>>>>>>>>>>>> >>>>>>>>>>>>> regards, >>>>>>>>>>>>> gerhard >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>> https://issues.apache.org/jira/browse/DELTASPIKE-124 >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.irian.at >>>>>>>>>>>>> >>>>>>>>>>>>> Your JSF/JavaEE powerhouse - >>>>>>>>>>>>> JavaEE Consulting, Development and >>>>>>>>>>>>> Courses in English and German >>>>>>>>>>>>> >>>>>>>>>>>>> Professional Support for Apache >> MyFaces >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/3/19 Mark Struberg >>>> <strub...@yahoo.de> >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is related to >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> https://issues.apache.org/jira/browse/DELTASPIKE-123 >>>>>>>>>>>>>> >>>>>>>>>>>>>> We had this discussion on the >> list and >>>> I already >>>>>>> got lots of >>>>>>>>>> questions >>>>>>>>>>> why >>>>>>>>>>>>>> we have those 'duplicated >>>> functions'. >>>>>>>>>>>>>> In fact I had to explain the >>>> differences a few >>>>>>> times already >>>>>>>>>> thus I >>>>>>>>>>>>>> decided to drop the start() and >> stop() >>>> methods and >>>>>>> make the >>>>>>>>>>> ContextControl >>>>>>>>>>>>>> easily accessible from the >> CdiContainer >>>> interface. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The current functionality is >> the >>>> following: >>>>>>>>>>>>>> * boot() will just boot the CDI >> >>>> container (Weld or >>>>>>> OWB) and >>>>>>>>>> _not_ start >>>>>>>>>>>>>> any Contexts. We don't do >> this >>>> implicitly >>>>>>> because we might >>>>>>>>>> not have all >>>>>>>>>>>>> the >>>>>>>>>>>>>> information. Of course this >> will have >>>> much more >>>>>>> impact once we >>>>>>>>>> also >>>>>>>>>>>>>> implemented not only the >> startContext() >>>> and >>>>>>> stopContext() in >>>>>>>>>> the >>>>>>>>>>>>>> ContextControl API but also >> added more >>>> information >>>>>>> about e.g. >>>>>>>>>>> sessionId, >>>>>>>>>>>>>> etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Especially if CDI is used in >> JavaSE we >>>> simply >>>>>>> don't know >>>>>>>>>> _which_ >>>>>>>>>>>>> Contexts >>>>>>>>>>>>>> are going to be used or if any >> of the >>>> built-in >>>>>>> contexts is >>>>>>>>>> being used >>>>>>>>>>> at >>>>>>>>>>>>>> all. In Java SE it could be >> possible >>>> that the whole >>>>>>> app just >>>>>>>>>> uses >>>>>>>>>>> custom >>>>>>>>>>>>>> scopes only! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thus your code will always look >> like >>>> the following >>>>>>>>>>>>>>> CdiContainer cdiCtr = >>>>>>>>>> CdiContainerLoader.getCdiContainer(); >>>>>>>>>>>>>>> cdiCtr.boot(); >>>>>>>>>>>>>> >>>>>>>>>>>>>> + >>>>>>>>>>>>>> >>>>>>>>>>>>>>> cdiCtr.getContextControl(). >> ... >>>> start whatever >>>>>>> builtin >>>>>>>>>> Context you >>>>>>>>>>>>> need. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Really, the use case that you >> like to >>>> start ALL >>>>>>> Contexts is >>>>>>>>>> _not_ the >>>>>>>>>>>>>> default! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Of course >>>>>>>>>>>>>> CdiContainer#shutdown() should >> also >>>> close all open >>>>>>> built-in >>>>>>>>>> Contexts >>>>>>>>>>>>>> properly (We should add this to >> the >>>> JavaDoc). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Btw, I now used boot() and >> shutdown() >>>> because this >>>>>>> is >>>>>>>>>> d'accord with the >>>>>>>>>>>>>> CDI specification (@Observes >>>> BeforeShutdown) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hope this helps understanding >> the >>>> situation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any objections? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>> strub >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>
