deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: CdiControl in Java EE?
Date Sat, 10 Mar 2012 13:51:19 GMT
> Each Request will e.g. get an own Context instance!
correction: MIGHT get it's own instance. This is container specific. 

LieGrue,
strub


----- Original Message -----
> From: Mark Struberg <struberg@yahoo.de>
> To: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@incubator.apache.org>
> Cc: 
> Sent: Saturday, March 10, 2012 2:21 PM
> Subject: Re: CdiControl in Java EE?
> 
> Hi!
> 
> I've now reviewed 
> 
> 
> https://cwiki.apache.org/DeltaSpike/cdi-11-proposals.html
> 
> 
> and I think the 
> 
> ManagedContext extends Context
> 
>  has a very basic defunct.
> 
> Let's look at the methods the Context interface defines:
> public Class<? extends Annotation> getScope();
> public <T> T get(Contextual<T> component);
> public <T> T get(Contextual<T> component, CreationalContext<T> 
> creationalContext);
> boolean isActive();
> 
> All these methods are targeted at a very Context instance. Each Request will 
> e.g. get an own Context instance!
> 
> But the ManagedContext interface defined in the wiki page is NOT yet bound to a 
> Request. It is more a ContextControl actually, because calling #start() will 
> actually even create a NEW Context! Those are completely orthogonal concerns 
> really.
> 
> Thus the is-a relation is just wrong imo. You just don't know upfront 
> whether you will get an existing Context or create a new Context.
> 
> LieGrue,
> strub
> 
> 
> ----- Original Message -----
>>  From: Mark Struberg <struberg@yahoo.de>
>>  To: "deltaspike-dev@incubator.apache.org" 
> <deltaspike-dev@incubator.apache.org>
>>  Cc: 
>>  Sent: Saturday, March 10, 2012 11:10 AM
>>  Subject: Re: CdiControl in Java EE?
>> 
>> G etting this back to life again!
>> 
>>  The next steps are
>> 
>>  1.) rename the project from cdise to cdicontrol because it is not only for 
> SE 
>>  anymore
>> 
>> 
>>  1.) split between the CdiBoot API and the ContextControl
>>   
>>  The CdiBoot is for starting and shutting down the container in SE 
> environments 
>>  and will be provided via the CdiBootLoader.
>> 
>>  The ContextControl will not be implemented via static accessor methods 
> anymore 
>>  but as @Dependent beans via CDI producers for each container. @Dependent 
> because 
>>  this context is always active.
>> 
>> 
>>  3.) we will for now just implement startContext and stopContext. We will 
> defer 
>>  activateContext and deactivateContext (in relation to the current thread) 
> until 
>>  later.
>> 
>>  wdyt?
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>>  ----- Original Message -----
>>>   From: Pete Muir <pmuir@redhat.com>
>>>   To: deltaspike-dev@incubator.apache.org; Mark Struberg 
>>  <struberg@yahoo.de>
>>>   Cc: 
>>>   Sent: Thursday, March 1, 2012 3:55 PM
>>>   Subject: Re: CdiControl in Java EE?
>>> 
>>>   Mark, are you saying you would like to be able to attach a backing 
> store 
>>  (e.g. 
>>>   map) and activate / detach the backing store and deactivate for 
> multiple 
>>  threads 
>>>   using one api call for all threads. Any idea what the API would look 
> like.
>>> 
>>>   I think this is one to consider later.
>>> 
>>>   On 29 Feb 2012, at 18:51, Mark Struberg wrote:
>>> 
>>>>    quick update:
>>>> 
>>>>    we might not only need start/stop context but also 
>>  'attach/detach'.
>>>> 
>>>>    Reason: the only important point for a Context if it is active 
> 'in 
>> 
>>>   respect to the current thread'.
>>>>    If you start a new thread manually, then there is no Context 
> active 
>>  for it. 
>>>   But for e.g. @SessionScoped, I don't like to create a new scope 
> for all 
>>  my 3 
>>>   Quartz worker threads but only once and and just 'attach' them 
> to 
>>  the 
>>>   other threads.
>>>> 
>>>>    LieGrue,
>>>>    strub
>>>> 
>>>> 
>>>> 
>>>>    ----- Original Message -----
>>>>>    From: Gerhard Petracek <gerhard.petracek@gmail.com>
>>>>>    To: deltaspike-dev@incubator.apache.org
>>>>>    Cc: 
>>>>>    Sent: Wednesday, February 29, 2012 6:46 PM
>>>>>    Subject: Re: CdiControl in Java EE?
>>>>> 
>>>>>    @mark:
>>>>>    that was exactly our intention.
>>>>> 
>>>>>    @others:
>>>>>    pete will simplify the api based on some objections and a 
> concrete
>>>>>    suggestion.
>>>>>    -> afterwards we could prototype and discuss it in 
> parallel.
>>>>> 
>>>>>    regards,
>>>>>    gerhard
>>>>> 
>>>>> 
>>>>> 
>>>>>    2012/2/29 Mark Struberg <struberg@yahoo.de>
>>>>> 
>>>>>>    sounds really good!
>>>>>> 
>>>>>>    we could introduce a subset of this stuff in DS and 
> provide a 
>>>   backward
>>>>>>    compatway for CDI-1.0 containers (beside using a 
> different 
>>  package)
>>>>>> 
>>>>>> 
>>>>>>    LieGrue,
>>>>>>    strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>    ----- Original Message -----
>>>>>>>    From: Pete Muir <pmuir@redhat.com>
>>>>>>>    To: deltaspike-dev@incubator.apache.org; Mark 
> Struberg 
>>  <
>>>>>>    struberg@yahoo.de>
>>>>>>>    Cc:
>>>>>>>    Sent: Wednesday, February 29, 2012 2:14 PM
>>>>>>>    Subject: Re: CdiControl in Java EE?
>>>>>>> 
>>>>>>>    T his just reinforces my feeling that CDIControl and 
>>  context 
>>>   lifecycle
>>>>>>    management
>>>>>>>    should be two separate APIs. Context control is 
> relevant 
>>  in 
>>>   Java EE 
>>>>>    and
>>>>>>    SE.
>>>>>>>    Container start/stop is only relevant in JavaSE.
>>>>>>> 
>>>>>>>    I would suggest that context lifecycle management 
> should 
>>  be 
>>>   dependent
>>>>>>    scoped
>>>>>>>    injectable bean(s), so that you can access it either 
> in a 
>>  CDI 
>>>   bean or
>>>>>>    outside a
>>>>>>>    CDI bean (and then control the other scopes).
>>>>>>> 
>>>>>>>    For inspiration for the context control, we could 
> look at 
>>  Weld, 
>>>   which
>>>>>>    defines an
>>>>>>>    API for context lifecycle management. As a quick 
> example:
>>>>>>> 
>>>>>>>    class Foo {
>>>>>>> 
>>>>>>>         @Inject RequestContext requestContext;
>>>>>>> 
>>>>>>>         void ensureRequestContextActive() {
>>>>>>>             if (!requestContext.isActive()) {
>>>>>>>                 requestContext.activate();
>>>>>>>             }
>>>>>>>         }
>>>>>>> 
>>>>>>>         void endRequest() {
>>>>>>>             if (requestContext.isActive()) {
>>>>>>>                 // e.g. Make sure any conversation that

> have 
>>  timed 
>>>   out are
>>>>>>    cleaned
>>>>>>>    up, we split this out so that we don't force 
> people to 
>>  do 
>>>   this, in 
>>>>>    case
>>>>>>    they
>>>>>>>    are just restarting the request context for some 
> reason
>>>>>>>                 requestContext.invalidate();
>>>>>>>                 requestContext.deactivate();
>>>>>>>             }
>>>>>>>         }
>>>>>>> 
>>>>>>>    }
>>>>>>> 
>>>>>>>    The API looks like:
>>>>>>> 
>>>>>>>    // We use an empty subclass to allow injecting by 
> type
>>>>>>>    public interface RequestContext extends 
> ManagedContext {}
>>>>>>> 
>>>>>>>    // Context is the standard CDI SPI
>>>>>>>    public interface ManagedContext extends Context {
>>>>>>> 
>>>>>>>        /**
>>>>>>>         * Activate the Context.
>>>>>>>         */
>>>>>>>        public void activate();
>>>>>>> 
>>>>>>>        /**
>>>>>>>         * Deactivate the Context, destroying any 
> instances if 
>>  the 
>>>   context 
>>>>>    is
>>>>>>>    invalid.
>>>>>>>         */
>>>>>>>        public void deactivate();
>>>>>>> 
>>>>>>>        /**
>>>>>>>         * Mark the context as due for destruction when 
>>  deactivate 
>>>   is 
>>>>>    called.
>>>>>>>         */
>>>>>>>        public void invalidate();
>>>>>>> 
>>>>>>>    }
>>>>>>> 
>>>>>>>    Note that Weld mixes this lifecycle management API in 
> with 
>>  an
>>>>>>    abstraction over
>>>>>>>    the context backing store (allowing you to use e.g. 
> the 
>>  http 
>>>   session, 
>>>>>    or
>>>>>>    a plain
>>>>>>>    map you manage yourself, or whatever you want). I 
>>  don't 
>>>   think we
>>>>>>    necessarily
>>>>>>>    need to introduce that to Deltaspike right now.
>>>>>>> 
>>>>>>>    A requested enhancement to this API for Weld, which I 
> 
>>  think we 
>>>   should
>>>>>>    support is
>>>>>>>    the ability to inject not only built in context 
> objects, 
>>  but 
>>>   any that
>>>>>>    the user
>>>>>>>    creates. I would suggest we do this based on 
> extending 
>>>   ManagedContext.
>>>>>>> 
>>>>>>>    When I wrote this, I modelled Request and Session 
>>  identically 
>>>   (as 
>>>>>    above).
>>>>>>>    ApplicationContext (and SingletonContext) is not 
> modelled 
>>  as a 
>>>   managed
>>>>>>    context,
>>>>>>>    as I don't expect a user to be able to activate 
> or 
>>>   deactivate it. 
>>>>>    The
>>>>>>>    Dependent context is also not modelled as a managed 
>>  context, as 
>>>   it has 
>>>>>    no
>>>>>>>    lifecycle. I did create an interface for it, which 
> simply 
>>>   extends
>>>>>>    Context with
>>>>>>>    no more methods, to allow consistent use of 
> injection.
>>>>>>> 
>>>>>>>    Conversation context is obviously the more complex 
> one ;-) 
>> 
>>>   It's 
>>>>>    modelled
>>>>>>    as
>>>>>>>    a managed context, and adds:
>>>>>>> 
>>>>>>>    * a method to access and mutate the parameter name 
> used to 
>> 
>>>   carry the
>>>>>>>    conversation id (the parameter is got from the 
> request 
>>  context 
>>>>>    object). I
>>>>>>>    don't think we should have this in Deltaspike, as 
> 
>>  it's 
>>>   outside 
>>>>>    the spec
>>>>>>>    by a long way ;-)
>>>>>>>    * a method to access and mutate the concurrent access 
> 
>>  timeout 
>>>>>    *default*
>>>>>>    for the
>>>>>>>    app. This is useful I think, and I would assume all 
> impls 
>>  do 
>>>   support
>>>>>>    this in
>>>>>>>    some way
>>>>>>>    * a method to access and mutate the conversation 
>>  inactivity 
>>>   timeout
>>>>>>    *default*
>>>>>>>    for the app. This is useful I think, and I would 
> assume 
>>  all 
>>>   impls do
>>>>>>    support
>>>>>>>    this in some way
>>>>>>>    * a method to get a list of all conversations the 
>>  container 
>>>   knows 
>>>>>    about
>>>>>>    (for
>>>>>>>    this session), returns a 
> List<ManagedConversation>, 
>>  more 
>>>   below
>>>>>>>    * a method to get the conversation by ID, returns 
>>>   ManagedConversation
>>>>>>>    * a method to have the container generate a new 
>>  conversation id 
>>>   using
>>>>>>    whatever
>>>>>>>    algorithm it wants
>>>>>>>    * a method to get the current active conversation
>>>>>>> 
>>>>>>>    ManagedConversation is a subclass of Conversation, 
> and 
>>  adds:
>>>>>>> 
>>>>>>>    * ability to lock and unlock the conversation 
> (concurrent 
>>>   access)
>>>>>>>    * get the timestamp the conversation was last used
>>>>>>>    * "touch" which updates the last used 
> timestamp 
>>  to 
>>>   now
>>>>>>> 
>>>>>>>    I'm not sure Deltaspike needs 
> ManagedConversation.
>>>>>>> 
>>>>>>>    You can read the full API at
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 
> https://github.com/weld/api/tree/master/weld/src/main/java/org/jboss/weld/context
>>>>>>>    - but ignore the sub packages, and the BoundContext 
>>  interface, 
>>>   as they
>>>>>>    relate to
>>>>>>>    abstracting out the backing store.
>>>>>>> 
>>>>>>>    I think this approach would give a powerful, easy to 
> use 
>>  API 
>>>   for 
>>>>>    context
>>>>>>>    lifecycle management. It also has the benefit of 
> ironing 
>>  out 
>>>   the
>>>>>>    differences
>>>>>>>    between built in and user provided contexts, and 
> provides 
>>  a 
>>>   model for
>>>>>>    extensions
>>>>>>>    to create context lifecycle management APIs based on.
>>>>>>> 
>>>>>>>    WDYT?
>>>>>>> 
>>>>>>>    On 29 Feb 2012, at 07:53, Mark Struberg wrote:
>>>>>>> 
>>>>>>>>      Hi!
>>>>>>>> 
>>>>>>>>      Pete did ask me a few days ago if the 
> CdiContainer 
>>  is 
>>>   really only
>>>>>>    targeted
>>>>>>>    to JavaSE.
>>>>>>>>      Well, basically it _was_. But yesterday I 
> reviewed 
>>  the 3 
>>>   Quartz
>>>>>>    Extensions
>>>>>>>    from Ronald, OpenKnowledge and Seam3 and when looking 
> at 
>>  the 
>>>   first 2 I
>>>>>>    saw that
>>>>>>>> 
>>>>>>>>      1.) OpenKnowledge introduces an own Context 
> named 
>>>   @ThreadScoped 
>>>>>    and
>>>>>>    start
>>>>>>>    it manually in the newly started Quartz thread.
>>>>>>>> 
>>>>>>>>      2.) our TISS Quartz Extension (done by Ronald) 
> uses 
>>  OWB 
>>>   specific 
>>>>>    code
>>>>>>    to
>>>>>>>    start a RequestScope for the newly started thread in 
> which 
>> 
>>>   Quartz 
>>>>>    runs.
>>>>>>>> 
>>>>>>>>      I've not looked into the Seam3 extension in 
> 
>>  detail 
>>>   because it 
>>>>>    does a
>>>>>>>    hell lot more and I'm not sure if we really need 
> all 
>>  that. 
>>>   A few 
>>>>>    things
>>>>>>    look
>>>>>>>    really good but I didn't have enough time to plug 
> them 
>> 
>>>   apart.
>>>>>>>> 
>>>>>>>>      What are the pros and cons of 1.) and 2.) so 
> far?
>>>>>>>>      1.) is CDI container independent but you must 
> not 
>>  use 
>>>>>    @RequestScoped
>>>>>>>    because this Context is not active in the new thread. 
> You 
>>  can 
>>>   use the 
>>>>>    new
>>>>>>>    @ThreadScoped but if you use the same @Transactional 
>>  services 
>>>   for the
>>>>>>    Quartz job
>>>>>>>    and the rest of your app, then you must not use a 
>>>   @RequestScoped
>>>>>>    EntityManager.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>      2.) Sharing the services between the Quartz job 
> and 
>>  the 
>>>   rest of 
>>>>>    the
>>>>>>    app is
>>>>>>>    perfectly fine but it's currently Container 
> specific 
>>  how 
>>>   the
>>>>>>    @RequestScoped
>>>>>>>    can get activated for a freshly created thread.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>      And then Pete's words jumped into my head.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>      So, what about using the
>>>>>>    CdiContainer#startContext(RequestScoped.class); in
>>>>>>>    that CDI Extension?
>>>>>>>>      That looks pretty much perfect to me!
>>>>>>>> 
>>>>>>>>      We could also provide multiple impls, e.g for: 
>>  WeldSE, 
>>>   WeldEE, 
>>>>>    OwbSE,
>>>>>>>    OwbEE, ResinEE,
>>>>>>>> 
>>>>>>>>      Anyone could easily implement the control part 
>>  himself if 
>>>   the 
>>>>>    standard
>>>>>>>    container integration doesn't work out of the box 
> for 
>>  a 
>>>   certain EE
>>>>>>>    container.
>>>>>>>>      If e.g. OwbEE will not work on WebSphere-8.0.2, 
> then 
>>  its 
>>>   easy to 
>>>>>    just
>>>>>>    write
>>>>>>>    an own!
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>      wdyt?
>>>>>>>> 
>>>>>>>>      LieGrue,
>>>>>>>>      strub
>>>>>>>> 
>>>>>>>> 
>>>>>>>>      PS: Pete we might add some kind of 
> Context-Control 
>>  to the 
>>>   CDI-1.1 
>>>>>    spec,
>>>>>>>    wdyt?
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 
> 

Mime
View raw message