deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS] start()/boot() vs stop()/shutdown()
Date Mon, 19 Mar 2012 14:08:32 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message