deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Porter" <lightguard...@gmail.com>
Subject Re: DISCUSS DeltaSpike-324
Date Thu, 21 Mar 2013 22:13:22 GMT
That's typically more pain for a user, and may cause issues with a service contract. I say
we implement this is DS for those who need it. 
—
Sent from Mailbox for iPhone

On Thu, Mar 21, 2013 at 3:50 PM, Arne Limburg
<arne.limburg@openknowledge.de> wrote:

> 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