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: CdiControl in Java EE?
Date Wed, 29 Feb 2012 10:53:28 GMT
hi mark,

i see the advantage as well as some others you haven't mentioned.

for most of them there are alternatives. the only real benefit (without
alternatives) i can see is the easier usage for users, because it would
"just" work.

however, as i saw with (both) cdi-se implementations, we need workarounds
for some (important) use-cases (i don't like them and we should remove them
as soon as we have released versions of weld and owb which fix the original
issues - but we need them to support at least the current versions of owb
and weld).
(we still don't have all tests we need -> we might need even more
workarounds for the current versions.)
in case of cdi-se that isn't a big issue, because users can switch to a new
version of owb or weld easily and we can drop the workarounds later on.
-> we just have to think about very few versions of owb and weld.

however, with pre-packaged cdi implementations it will be more complicated
and we have to provide modules for a lot of servers and in the worst case
workarounds for multiple versions of a server.
esp. if different server versions need to be supported, it can get
complicated for users and even more complicated as soon as they have to
deploy such an application to different servers (or different versions of a
server).
(+ we can't drop the workarounds easily.)
you are right - users >could< implement it on their own. but they shouldn't
have to care about it!

-> imo the advantage that it would just work and it's easy for users
doesn't work in the end.
-> -1 for server specific >modules< and +1 for including the needed parts
in cdi 1.1 and using a portable approach for cdi 1.0 (if it makes sense we
can switch the approach for the version of deltaspike which is compatible
with cdi 1.1 later on).

regards,
gerhard



2012/2/29 Jason Porter <lightguard.jp@gmail.com>

> All sounds good to me.
>
> We could try to get Peter Royal to explain Seam 3 Cron, but I'm not sure
> what his availability is.
>
> On Wed, Feb 29, 2012 at 00:53, Mark Struberg <struberg@yahoo.de> 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?
> >
> >
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message