deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Gonzalez <adr_gonza...@yahoo.fr>
Subject Re: DISCUSS DeltaSpike-324
Date Sun, 24 Mar 2013 19:02:35 GMT
Hello,

I'm a DS user (and I'm not the only one I think).

Just to let you know how I use it (if this can help someone) : DS 0.3 with a mix of CODI and
2/3 classes from Seam [1].

Quite happy for now (I'm using DS Exception handling - with custom REST and JSF extensions
from Seam 3, Config).


From CODI, I use WindowScoped, ConversationScoped and ViewAccessScoped.

From Seam 3, I use a modified version JSF ExceptionHandling (to integrate to DS Exception
Handling), UIInputContainer (completely optional, but I like it), and REST Exception Handling.
Only JSF ExceptionHandling is really mandatory IMO.

For the rest of my application CMT EJB Stateless (tx) and @PersistenceContext (no extended).

I'll remove CODI when CODI scopes are ported to DS which should be DS 0.4 if I'm correct.


Best regards,

[1] Most notably : https://github.com/seam/faces/tree/develop/impl/src/main/java/org/jboss/seam/faces/exception


________________________________
 De : Romain Manni-Bucau <rmannibucau@gmail.com>
À : deltaspike-dev@incubator.apache.org 
Envoyé le : Dimanche 24 mars 2013 19h33
Objet : Re: DISCUSS DeltaSpike-324
 
I did a JUG this week with a part on DS and was the main question asked
with those words "when will it be usable?"...kind of sad. Releasing even in
alpha/beta is better IMO.
Le 24 mars 2013 19:29, "Jason Porter" <lightguard.jp@gmail.com> a écrit :

> +1 glad I'm not the only one asking for a roadmap now.
> —
> Sent from Mailbox for iPhone
>
> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> <rmannibucau@gmail.com> wrote:
>
> > Do we already have a roadmap? I think we should define one by iteration
> > (+handle a backlog if we want).
> > I can help on cdi query part if needed (jsf is still a bit too new for
> me).
> > Le 24 mars 2013 18:49, "Gerhard Petracek" <gerhard.petracek@gmail.com> a
> > écrit :
> >> hi john,
> >>
> >> we can't keep it currently (i'm also unhappy about it), because if only
> 2-3
> >> people help on a >regular< basis [1], you have to wait until they have
> >> time.
> >> it isn't only about unassigned issues. e.g. not that many help with
> writing
> >> tests and examples, writing/reviewing javadoc and documentation.
> >>
> >> even the graduation process takes (very) long.
> >> that might be a big blocker for some users.
> >> at least codi had several users way before v1 (and for sure even more
> after
> >> v1).
> >> however, we would lose more users, if we release v1 which isn't ready.
> >>
> >> >imo< our goal for v1 should be >at least< everything (which we
know
> >> already) we need for improving the java-ee web-profile as well as a
> stable
> >> api and spi.
> >>
> >> regards,
> >> gerhard
> >>
> >> [1] https://github.com/apache/incubator-deltaspike/contributors
> >>
> >>
> >>
> >> 2013/3/24 Romain Manni-Bucau <rmannibucau@gmail.com>
> >>
> >> > I get you and think we agree behund words. My main issue is our 0.4 is
> >> not
> >> > ready to be released and still doesnt contain what users are waiting
> >> for...
> >> >
> >> > When i spoke about > 1.0 just understand when last release answer
> basic
> >> > needs
> >> > Le 24 mars 2013 16:49, "John D. Ament" <john.d.ament@gmail.com> a
> écrit
> >> :
> >> >
> >> > > Romain,
> >> > >
> >> > > I'm not sure what to tell you.  One of our founding statements was
> >> > release
> >> > > early and often.  I'm not sure why we haven't stuck to that.
> >> >  Personally, I
> >> > > think we have failed to do that.  We probably have too many features
> >> in a
> >> > > single release/ not much release planning/attempt to release
> everything
> >> > as
> >> > > one big release rather than more modular in nature.  Those are just
> >> > > thoughts.
> >> > >
> >> > > As I already stated, I don't want this in 0.4.  But I don't think
> it's
> >> > > appropriate to stick this in after 1.0, who knows when that will
> be.  I
> >> > > would love to see this in 0.5, already have prototypes working. 
My
> >> > biggest
> >> > > issue, as I was trying to raise in the other thread, is that when
> >> people
> >> > > look at the issue list out there, generally the candidates to work
> on
> >> are
> >> > > the unassigned issues.  If 80% of what we have out there is
> assigned,
> >> > then
> >> > > it's assumed someone's work on it.  If it's assigned to someone and
> >> > they're
> >> > > not working on it, that's probably an issue that needs to be
> addressed.
> >> >  As
> >> > > far as I can tell, of the 10 unassigned issues out there, none of
> them
> >> > are
> >> > > comprehensible enough (other than the one I already worked on) to
be
> >> > worked
> >> > > through.  So I'm not sure, maybe it's an issue of perception, but
I
> >> don't
> >> > > think we have a large pile of open work for future releases.
> >> > >
> >> > > John
> >> > >
> >> > >
> >> > > On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> >> > > <rmannibucau@gmail.com>wrote:
> >> > >
> >> > > > Sure but we cant start everything, finishing nothing...our rare
> >> > releases
> >> > > > are already a pain for users.
> >> > > >
> >> > > > We need jsf + if possible cdi query for 0.4 IMO then i agree
rest
> >> > helpers
> >> > > > are a must have (some tools around jaxrs client part can be great)
> >> > etc...
> >> > > > Le 24 mars 2013 16:13, "John D. Ament" <john.d.ament@gmail.com>
a
> >> > écrit
> >> > > :
> >> > > >
> >> > > > > Romain,
> >> > > > >
> >> > > > > My only issue with this is that I don't think we've mapped
out
> what
> >> > the
> >> > > > > common use cases are (at least based on the email I sent
out).
>  If
> >> > > we're
> >> > > > > favoring JSF, we're neglecting the growing population of
REST
> APIs
> >> > for
> >> > > > rich
> >> > > > > javascript clients (from UI).
> >> > > > >
> >> > > > >
> >> > > > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> >> > > > > <rmannibucau@gmail.com>wrote:
> >> > > > >
> >> > > > > > yes but JMS is clearly not the most used
> >> > > > > >
> >> > > > > > can't we push it for the > 1.0?
> >> > > > > >
> >> > > > > > users really wait the first 1.0 to use DS and adding
JMS now
> >> simply
> >> > > > looks
> >> > > > > > like forgetting more common use cases
> >> > > > > >
> >> > > > > > *Romain Manni-Bucau*
> >> > > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >> > > > > > *Blog: **http://rmannibucau.wordpress.com/*<
> >> > > > > > http://rmannibucau.wordpress.com/>
> >> > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> > > > > > *Github: https://github.com/rmannibucau*
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > 2013/3/23 Gerhard Petracek <gerhard.petracek@gmail.com>
> >> > > > > >
> >> > > > > > > hi @ all,
> >> > > > > > >
> >> > > > > > > imo it's more a basic question.
> >> > > > > > > if we do it for jms 2, we also have to (/should)
do it for
> >> other
> >> > > > > > > specifications like bv 1.1
> >> > > > > > >
> >> > > > > > > regards,
> >> > > > > > > gerhard
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > 2013/3/21 Romain Manni-Bucau <rmannibucau@gmail.com>
> >> > > > > > >
> >> > > > > > > > Ill rephrase a bit. I m rather -0 about it
and -1 since a
> lot
> >> > of
> >> > > > > others
> >> > > > > > > > stuff are needed before.
> >> > > > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> >> > > > arne.limburg@openknowledge.de
> >> > > > > >
> >> > > > > > a
> >> > > > > > > > écrit :
> >> > > > > > > >
> >> > > > > > > > > We should find out if one can simply
use a JMS 2.0
> >> > > implementation
> >> > > > > and
> >> > > > > > > put
> >> > > > > > > > > it into an deployment. If that will
be possible, we
> would
> >> not
> >> > > > need
> >> > > > > to
> >> > > > > > > > > implement it.
> >> > > > > > > > >
> >> > > > > > > > > Cheers,
> >> > > > > > > > > Arne
> >> > > > > > > > >
> >> > > > > > > > > Am 21.03.13 22:34 schrieb "Mark Struberg"
unter <
> >> > > > struberg@yahoo.de
> >> > > > > >:
> >> > > > > > > > >
> >> > > > > > > > > >I tend to lean towards +1 simply
because EE-7
> containers
> >> > will
> >> > > > take
> >> > > > > > > > > >another year (or 2) to become used
in projects.
> >> > > > > > > > > >
> >> > > > > > > > > >I just think we should first close
a few tasks before
> we
> >> > open
> >> > > > new
> >> > > > > > > ones.
> >> > > > > > > > > >
> >> > > > > > > > > >LieGrue,
> >> > > > > > > > > >strub
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >----- Original Message -----
> >> > > > > > > > > >> From: John D. Ament <john.d.ament@gmail.com>
> >> > > > > > > > > >> To: deltaspike-dev@incubator.apache.org
> >> > > > > > > > > >> Cc:
> >> > > > > > > > > >> Sent: Thursday, March 21, 2013
6:09 PM
> >> > > > > > > > > >> Subject: Re: DISCUSS DeltaSpike-324
> >> > > > > > > > > >>
> >> > > > > > > > > >> Romain,
> >> > > > > > > > > >>
> >> > > > > > > > > >> Generally, I'm mixed about
these.  However I think
> >> there's
> >> > > > some
> >> > > > > > > pretty
> >> > > > > > > > > >> good
> >> > > > > > > > > >> benefits.  For an application
developer, maybe none
> of
> >> the
> >> > > > other
> >> > > > > > > JMS 2
> >> > > > > > > > > >> features are useful to you
(the bulk of the feature
> went
> >> > > into
> >> > > > > CDI
> >> > > > > > > > > >>support,
> >> > > > > > > > > >> app server integration, and
documentation clean up).
> >>  You
> >> > > > don't
> >> > > > > > want
> >> > > > > > > > to
> >> > > > > > > > > >> move off of TomEE 1.5.x to
TomEE Y (which could
> support
> >> > Java
> >> > > > EE
> >> > > > > 7
> >> > > > > > > Web
> >> > > > > > > > > >> Profile) due to downtime in
your application.
>  There's
> >> > also
> >> > > > lead
> >> > > > > > > time
> >> > > > > > > > > >> required to impelement JMS
2/Java EE 7 features in
> your
> >> > > > > > application
> >> > > > > > > > > >>server,
> >> > > > > > > > > >> but perhaps you don't want
to or need to wait for the
> >> > whole
> >> > > > > thing.
> >> > > > > > > > > >>
> >> > > > > > > > > >> This solution would be DS oriented,
I believe
> requires
> >> > > > > > > > TransactionScoped
> >> > > > > > > > > >> (which could require the transaction
classes be moved
> >> away
> >> > > > from
> >> > > > > > > > > >> persistence) to operate properly.
> >> > > > > > > > > >>
> >> > > > > > > > > >> There's also the case of using
DeltaSpike as your
> >> CDI-JMS
> >> > > > > > > > > >>implementation if
> >> > > > > > > > > >> you were a JMS implementer. 
I haven't reached out to
> >> > > > > communities
> >> > > > > > > such
> >> > > > > > > > > >>as
> >> > > > > > > > > >> Apache ActiveMQ or HornetQ
to see input here; I know
> the
> >> > > > current
> >> > > > > > > > > >>GlassFish
> >> > > > > > > > > >> implementation calls their
lower level directly (and
> not
> >> > by
> >> > > > > > wrapping
> >> > > > > > > > the
> >> > > > > > > > > >> JMS APIs).
> >> > > > > > > > > >>
> >> > > > > > > > > >> John
> >> > > > > > > > > >>
> >> > > > > > > > > >>
> >> > > > > > > > > >> On Thu, Mar 21, 2013 at 12:30
PM, Romain Manni-Bucau
> >> > > > > > > > > >> <rmannibucau@gmail.com>wrote:
> >> > > > > > > > > >>
> >> > > > > > > > > >>>  Hi
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>  i'm globally -1 for redoing
something which will
> exist
> >> > > > > somewhere
> >> > > > > > > > else
> >> > > > > > > > > >>>  (basically if somebody
wants JavaEE just let him
> use
> >> > > JavaEE,
> >> > > > > CDI
> >> > > > > > > > > >> doesn't
> >> > > > > > > > > >>>  need the full stack IMO).
Was my point for JPA,
> more
> >> > again
> >> > > > on
> >> > > > > > JMS.
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>  It is great to add feature
before the specs not
> once
> >> it
> >> > is
> >> > > > (or
> >> > > > > > > > almost)
> >> > > > > > > > > >>>  done.
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>  Maybe i didnt fully get
what you want to do so
> maybe
> >> > share
> >> > > > > some
> >> > > > > > > > > >>>pastebin to
> >> > > > > > > > > >>>  be sure we speak about
the same stuff.
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>  *Romain Manni-Bucau*
> >> > > > > > > > > >>>  *Twitter: @rmannibucau
<
> >> https://twitter.com/rmannibucau
> >> > >*
> >> > > > > > > > > >>>  *Blog: **http://rmannibucau.wordpress.com/*<
> >> > > > > > > > > >>>  http://rmannibucau.wordpress.com/>
> >> > > > > > > > > >>>  *LinkedIn: **
> http://fr.linkedin.com/in/rmannibucau*
> >> > > > > > > > > >>>  *Github: https://github.com/rmannibucau*
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>  2013/3/21 John D. Ament
<john.d.ament@gmail.com>
> >> > > > > > > > > >>>
> >> > > > > > > > > >>>  > All,
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > I'd like to open
the floor to discussion for
> porting
> >> > > JMS 2
> >> > > > > > > > > >> features to
> >> > > > > > > > > >>>  > DeltaSpike, specifically
the features that added
> >> some
> >> > > CDI
> >> > > > > > > > > >>>capabilities
> >> > > > > > > > > >> to
> >> > > > > > > > > >>>  > JMS.
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > Details of my rough
proposal are here:
> >> > > > > > > > > >>>  >
> >> https://issues.apache.org/jira/browse/DELTASPIKE-324
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > Importing these
features start to deprecate
> >> > > functionality
> >> > > > in
> >> > > > > > > Seam
> >> > > > > > > > > >>>JMS
> >> > > > > > > > > >>>  > (ideal).  These
features would give access to an
> API
> >> > > very
> >> > > > > > > similar
> >> > > > > > > > > >>>to
> >> > > > > > > > > >> the
> >> > > > > > > > > >>>  > JMS2 API around
CDI injection.
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > Some limitations:
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > - This would not
be a JMS implementation, simply
> an
> >> > > > inspired
> >> > > > > > > > > >>>interface
> >> > > > > > > > > >>>  for
> >> > > > > > > > > >>>  > use in Java EE 6/JMS
1.x that leveraged CDI
> >> injection
> >> > > > based
> >> > > > > on
> >> > > > > > > the
> >> > > > > > > > > >> rules
> >> > > > > > > > > >>>  > for CDI injection
of these interfaces.  We would
> >> bring
> >> > > in
> >> > > > > very
> >> > > > > > > > > >>>similar
> >> > > > > > > > > >>>  > annotations that
supported the injection of the
> >> three
> >> > > > target
> >> > > > > > > > types.
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > - Cannot use the
exact interface, since the
> >> interface
> >> > > > > > implements
> >> > > > > > > > > >>>  > AutoCloseable which
is a Java SE 7 interface.
> >> > >  DeltaSpike
> >> > > > > uses
> >> > > > > > > > Java
> >> > > > > > > > > >>>SE
> >> > > > > > > > > >> 6
> >> > > > > > > > > >>>  > for a compiler.
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > - Internally these
would have to use the current
> JMS
> >> > > > > > interfaces
> >> > > > > > > of
> >> > > > > > > > > >>>  > connection, session.
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > - Testing would
be feasible but require a full
> Java
> >> EE
> >> > > > > > container
> >> > > > > > > > > >>>(e.g.
> >> > > > > > > > > >> no
> >> > > > > > > > > >>>  > testing in Weld/OWB
directly) that supported
> >> > deployment
> >> > > of
> >> > > > > > > > > >> destinations
> >> > > > > > > > > >>>  at
> >> > > > > > > > > >>>  > runtime.  Since
this doesn't touch MDBs we can
> >> > manually
> >> > > > read
> >> > > > > > > from
> >> > > > > > > > > >> the
> >> > > > > > > > > >>>  > destination.
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>  > John
> >> > > > > > > > > >>>  >
> >> > > > > > > > > >>>
> >> > > > > > > > > >>
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message