That's typically more pain for a user, and may cause issues with a service contract. I say we implement this is DS for those who need it. — Sent from Mailbox for iPhone
On Thu, Mar 21, 2013 at 3:50 PM, Arne Limburg <[email protected]> wrote: > 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 >>>> > >>>> >>>
