deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject Re: DISCUSS DeltaSpike-324
Date Thu, 21 Mar 2013 21:49:36 GMT
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
View raw message