deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: DISCUSS DeltaSpike-324
Date Sat, 23 Mar 2013 22:04:23 GMT
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