deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] start()/boot() vs stop()/shutdown()
Date Mon, 19 Mar 2012 15:27:46 GMT
gnahhh stopContexts() DOES work as expected!

A user can still disable the proxy caching as shown in my post already IF a user likes to
get rid of @ApplicationScoped beans
(which I don't think he ever will).

The main use case is for sure making @RequestScope, @SessionScoped and @ConversationScoped
working with SE (unit tests, etc) and EE (new threads).
Bring me a use case and I will think about it.

If a user really needs a restartable Application Context within his app and he is using OWB,
then he will surely find the well-documented caching behaviour of the proxy used by default.


Again: bring me a use case and I will bring you a solution!
I'm fine with pointing out this specific question in the documentation, but thats by far no
reason to drop the whole feature!


LieGrue,
strub



----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Monday, March 19, 2012 4:09 PM
> Subject: Re: [DISCUSS] start()/boot() vs stop()/shutdown()
> 
> i'm still ok with B) (as it is right now), >if< cdi 1.1 will support 
> it
> (for now we could document the use-cases which aren't supported).
> 
> however, since the current implementation of #stopContexts doesn't work as
> expected (out-of-the-box), +1 for removing it (and we have to ensure that
> all contexts are stopped by CdiContainer#shutdown).
>> if< we have use-cases for #startContexts (without #stopContexts), i still
> vote +1 for a convenience method for starting the container and the
> contexts with one call (instead of two).
> if we don't have them, +1 for removing #startContexts as well.
> 
> regards,
> gerhard
> 
> 
> 
> 2012/3/19 Pete Muir <pmuir@redhat.com>
> 
>>  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 <pmuir@redhat.com>
>>  >> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
>>  struberg@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 <pmuir@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 <struberg@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 <pmuir@redhat.com>
>>  >>>>>>> To: deltaspike-dev@incubator.apache.org
>>  >>>>>>> Cc: Mark Struberg <struberg@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 
> <struberg@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.petracek@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 
> <pmuir@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.petracek@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
>>  >>>> <struberg@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
>>  >>>>>>>>>>>>>>
>>  >>>>>>>>>>>>>>
>>  >>>>>>>>>>>>>
>>  >>>>>>>>>>>
>>  >>>>>>>>>>>
>>  >>>>>>>>>>
>>  >>>>>>>>>
>>  >>>>>>>
>>  >>>>>>
>>  >>>>
>>  >>
>> 
>> 
> 

Mime
View raw message