I totally got you the first time Mark :-) 20+ years experience or not, creating a separate class (subclass or otherwise) for doing this particular job stinks IMO, sorry ;-) Anyway I'm actually all for getting rid of it coz I do agree that it's a broken concept, but not because of anything to do with OO, CORBA, DCE, DCOM RMI etc When you think about it, what's the likelihood of only having 1 DLQ in a system. Not sure if we currently support it or not, but I'd imagine that at some stage we'll need to support DLQ config on a per endpoint/Service basis (as well as a system wide default perhaps) and this method would gag on that. I do think however that we should try make DLQ delivery as easy as possible and that people shouldn't need to manually "look up" the DLQ in their code and call any special classes. I think we should be able to associate a DLQ with one or more Services/endpoints and have the SI take care of it all from a code perspective e.g. try deliver a message through the SI.... if it fails, SI auto delivers to the service's associated DLQ, OR the calling code can manually do it via the SI instance. Auto doing it would be in line with how the likes of Weblogic does it for JMS (you can configure a DLQ per JMS Destination) and I think it's more in line with the old fire-and-forget line of thinking (otherwise it'd be fire-and-forget-unless-theres-an-error). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070941#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...