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 <[email protected]>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 <[email protected]> > > > 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 > > >
