Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gerhard.petracek@gmail.com
 designates 209.85.160.175 as permitted sender)
Received-SPF: pass (google.com: domain of gerhard.petracek@gmail.com
 designates 10.236.178.65 as permitted sender) client-ip=10.236.178.65;
MIME-Version: 1.0
In-Reply-To: <1330536320.83209.YahooMailNeo@web171519.mail.ir2.yahoo.com>
References: <1330501987.47796.YahooMailNeo@web171511.mail.ir2.yahoo.com>
 <E29C80CE-0E3D-4D3D-A806-828B093DCD53@redhat.com>
 <1330536320.83209.YahooMailNeo@web171519.mail.ir2.yahoo.com>
From: Gerhard Petracek <gerhard.petracek@gmail.com>
Date: Wed, 29 Feb 2012 18:46:01 +0100
Message-ID: 
 <CAGJtJfFyXekKPZ8qTjjjnonsL8Kc7j1K5SrSHZ2+T_D1E-froA@mail.gmail.com>
Subject: Re: CdiControl in Java EE?
To: deltaspike-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf3040e4d0e2ae1d04ba1deb6b

--20cf3040e4d0e2ae1d04ba1deb6b
Content-Type: text/plain; charset=ISO-8859-1

@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?
> >>
> >
>

--20cf3040e4d0e2ae1d04ba1deb6b--