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 14:30:48 GMT
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