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 >
