Invalidate will get you 99% of the way there - it destroys all the beans, and clears the backing store. However it won't make the context inactive. So I guess I was wrong - you can restart the context effectively , but you can't discretely stop or start it…
On 19 Mar 2012, at 14:32, Gerhard Petracek wrote: > hi pete, > > in my test it worked > with org.jboss.weld.context.ApplicationContext#invalidate > > regards, > gerhard > > > > 2012/3/19 Pete Muir <pm...@redhat.com> > >> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> >>
