RE: [Springframework-developer] JMS brainstorming

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

That sounds great! We also have need to support stanadalone jms =
applications. Other items on your list would be of interest to us too.=20

Is there any chance we can see the code?

Thanks,

Rong

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
> On Behalf
> Of Mark Pollack
> Sent: Friday, February 27, 2004 5:12 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] JMS brainstorming
>=20
>=20
> Hi everyone,
>=20
> I'll look over the code this weekend...on a little vacation now.
> Anyway, sounds good so far.  I'm in the middle of discussing=20
> donating JMS
> code we developed at our company...
>=20
> Some of the larger items are:
>=20
> 1. A very efficient implementation of the JMS selector for use on
> MapMessages, or really anything else you like, hashtables, even text
> messages.  Based on JavaCC. This externalized the ugly switch=20
> statements
> that you typically have to do in the main callback function.
>=20
> 2. We have a 'standalone' jms application, not in an=20
> appserver.  We added
> some server like infrastructure classes to spring start up the
> connections, sessions, etc., after all the bean=20
> initialization.  There are
> corresponding classes to handle setting up all the JMS=20
> specific stuff...tx
> session, what ack mode, etc.  Vendors also make extensions to=20
> the standard
> modes that we should account for...
>=20
> 3. Much like the templates for jdbc etc. there is a bunch of=20
> surrounding
> code to handle exceptions correctly, also having a seperate method for
> "onDuplicate" based on the JMSHeader value is nice.
>=20
> 4. A 'pipe and filters' style processing framwork.  Similar=20
> to what you
> might see in apache axis, but not specific to soap or jms. =20
> It it based on
> the reactor design pattern to pick off the appropriate=20
> processing chain to
> execute based on the evaluation of a JMS selector string that=20
> applies to
> the message body (not the header).  It then iterates through various
> 'process' template methods of modules in the chain..=20
> exceptions result in
> rolling back, that is calling 'rollback' up the chain and finally to a
> exceptionhandler.  This is all externalized in a config file.=20
>  I'm sure
> there might be temptations to compare to other workflow like=20
> projects...
> but this codebase is really pretty simple and has been=20
> extremely useful to
> us for a number of years....  It really also apply outside=20
> the messaging
> area...
>=20
> 5. Some pretty print utilities for messages, xml=20
> marhsaller/unmarshaller.=20
> This is part of my conversion/rewrite/refactoring of=20
> 'rvtest.sf.net (JUnit
> for TIBCO Rendezvous to JMS) I'll be releasing that code on=20
> sf but we can
> pick and choose little things that might be useful...
>=20
> I'm pretty sure most I can integrate most of the items on=20
> this list to the
> effort.
>=20
>=20
> Cheers,
> Mark
>=20
>=20
>=20
> > Hi Rod, Hi All,
> >
> > I've been working on the JMS support for a few weeks now=20
> and I think I'm
> > ready to go public with it to find out your opinion. So=20
> far, I got Mark to
> > volunteer to look at the code, make suggestions and=20
> possibly contribute
> > some
> > code. If anybody is interested to look at it as well, just=20
> 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=20
> 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=20
> 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=20
> messaging. I did
> > include support for both durable and non-durable messaging.
> > 2. The consumers will be able to not only create messages,=20
> but also will
> > have some control over how they will be delivered. I.e.=20
> modify default
> > delivery mode, priority, time to live.
> > 3. Message listeners will be instrumental in automatically=20
> registering
> > beans
> > as subscribers to topics and queues.
> >
> > I left out support for the transacted sessions. Sessions=20
> created are all
> > set
> > to "no-transaction" and "auto-ACK". Is this something we=20
> 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=20
> joining the
> >>Spring team soon.
> >>
> >>Andre, if you want to share your work in progress with the=20
> 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=20
> JMS. I heard
> >>rumors that JMS support will be added to Spring 1.1, but we=20
> just can't
> >> wait
> >>that long. So I am thinking about doing something in the=20
> 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=20
> 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=20
> days. So to
> >> all
> >>you experienced Spring'ers, if you were to add JMS support=20
> today, what
> >>would
> >>you do? I am still fairly new to Spring, so any suggestions=20
> 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_id=1356&alloc_id438&op=3Dick
> >>_______________________________________________
> >>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=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> 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_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer