Menu
▾
▴
Re: [Springframework-developer] JMS brainstorming
|
From: Rod J. <rod...@in...> - 2004-03-02 07:16:39
|
What are the release levels of the major services (WLS, WS, JB etc.) to support 1.1? ----- Original Message ----- From: "Mark Pollack" <mar...@co...> To: <spr...@li...> Sent: Tuesday, March 02, 2004 12:02 AM Subject: RE: [Springframework-developer] JMS brainstorming Hi, I've added Andre's code into the sandbox. I'd like to get some input on the following.... Can we count on using the JMS 1.1 API or should we be compatible with the JMS 1.0.2 API? The reason is that JMS 1.1 introduced "domain unification", meaning that there the classes are no longer split into "Queue" and "Topic" class hierarchies. The code can now refer to a "ConnectionFactory" instead of it being a "QueueConnectionFactory" or a "TopicConnectionFactory". This applies up and down the class hierarchy since the split is rather high level. The end result is that using the JMS 1.1 api makes the client code much easier to use since there is less obvious duplication. Other advantages can be read in the spec...such as being able to use queues and topics in the same transaction (probably since they now can share the same Session object). The templates now are written using the 1.0.2 style classes, which I haven't used in a long time....but I'd like to hear what people are using considering how much it will affect the shape of the code... I'd vote for dropping 1.0.2 support. Cheers, Mark -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Andre Biryukov Sent: Thursday, February 26, 2004 11:46 AM To: rod...@in...; spr...@li... Subject: Re: [Springframework-developer] JMS brainstorming Hi Rod, Hi All, I've been working on the JMS support for a few weeks now and I think I'm ready to go public with it to find out your opinion. So far, I got Mark to volunteer to look at the code, make suggestions and possibly contribute some code. If anybody is interested to look at it as well, just drop me a mail, I'll be happy to forward what I have so far to you. I'm not only interested in the feedback about the code, but would like to hear opinions on what we should include and what not. The API for messaging is huge, well, big. The challenge is to try and put as much functionality as possible, but at the same token, try not to make it look complex. Here's the list of things I've implemented: 1. Templates for publish/subscribe and point-to-point messaging. I did include support for both durable and non-durable messaging. 2. The consumers will be able to not only create messages, but also will have some control over how they will be delivered. I.e. modify default delivery mode, priority, time to live. 3. Message listeners will be instrumental in automatically registering beans as subscribers to topics and queues. I left out support for the transacted sessions. Sessions created are all set to "no-transaction" and "auto-ACK". Is this something we would like to see in the framework or should we just keep it simple for now ? The more suggestions I get now, the better, so please open the flood gate. :) Thanks, Andre. >From: "Rod Johnson" <rod...@in...> >To: <spr...@li...> >CC: "Andre Biryukov" <and...@ho...> >Subject: Re: [Springframework-developer] JMS brainstorming >Date: Thu, 26 Feb 2004 06:35:33 -0000 > >Rong > >JMS support is in the works, and should make 1.1. > >Andre Biryukov is currently working on this, and should be joining the >Spring team soon. > >Andre, if you want to share your work in progress with the Spring dev >list (or with Rong directly), now would be a good time :-) > >Regards, >Rod > >----- Original Message ----- >From: "Ou, Rong" <Ro...@sa...> >To: <spr...@li...> >Sent: Tuesday, February 24, 2004 9:44 PM >Subject: [Springframework-developer] JMS brainstorming > > >Hi all, > >We currently have a project that does a lot of JMS messaging, and we >desperately need an API to simplify the interface layer to JMS. I heard >rumors that JMS support will be added to Spring 1.1, but we just can't >wait that long. So I am thinking about doing something in the interim. >Who knows, if it comes out good, maybe I can contribute the code back. > >In Rod's book there is only a couple of pages that briefly touches upon >JMS. >I looked at the interface21 code, the JMS portion is also pretty >simplistic. >I understand Spring has evolved a lot since the interface21 days. So to all >you experienced Spring'ers, if you were to add JMS support today, what >would >you do? I am still fairly new to Spring, so any suggestions and help are >welcome. > >Thanks, > >Rong > > >------------------------------------------------------- >SF.Net is sponsored by: Speed Start Your Linux Apps Now. >Build and deploy apps & Web services for Linux with >a free DVD software kit from IBM. Click Now! >http://ads.osdn.com/?ad_id56&alloc_id438&op=ick >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > _________________________________________________________________ Stay informed on Election 2004 and the race to Super Tuesday. http://special.msn.com/msn/election2004.armx ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=ick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
