deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: DISCUSS DeltaSpike-324
Date Thu, 21 Mar 2013 21:34:45 GMT
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