Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others stuff are needed before. Le 21 mars 2013 22:50, "Arne Limburg" <[email protected]> a écrit :
> 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 <[email protected]>: > > >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 <[email protected]> > >> To: [email protected] > >> 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 > >> <[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 > >>> > > >>> > >> > >
