Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org Received: (qmail 1667 invoked from network); 26 Sep 2003 19:04:35 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 26 Sep 2003 19:04:35 -0000 Received: (qmail 71157 invoked by uid 500); 26 Sep 2003 19:04:17 -0000 Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 71097 invoked by uid 500); 26 Sep 2003 19:04:16 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 71082 invoked from network); 26 Sep 2003 19:04:16 -0000 Received: from unknown (HELO ms-smtp-03.rdc-kc.rr.com) (24.94.166.129) by daedalus.apache.org with SMTP; 26 Sep 2003 19:04:16 -0000 Received: from [10.0.1.2] (CPE-24-26-167-75.mn.rr.com [24.26.167.75]) by ms-smtp-03.rdc-kc.rr.com (8.12.8p1/8.12.7) with ESMTP id h8QJ4Drv012697 for ; Fri, 26 Sep 2003 14:04:20 -0500 (CDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 26 Sep 2003 14:04:12 -0500 Subject: Re: MDB support From: Richard Monson-Haefel To: Message-ID: In-Reply-To: <38241668-EFEF-11D7-A701-003065F4889C@snappydsl.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Yes, I agree. That's a solution you can use to get your unit tests in place, because it allows you to control the delivery of messages and the interaction between the faux JCA resource and the MDB container. I guess I was talking about a production system. Still, the MDB container itself should be designed to adhere to the JCA message-delivery contract even if the resource you are using is designed purely for testing. Did I understand your post, or am I off on a tangent? Richard -- Richard Monson-Haefel Co-Founder\Developer, Apache Geronimo Author of: J2EE Web Services (AW 2003) Enterprise JavaBeans, 4ed (O'Reilly 2004) Java Message Service (O'Reilly 2000) http://www.Monson-Haefel.com On 9/26/03 2:01 AM, "David Jencks" wrote: > Yes, but James can probably write an mbean that uses the jca 1.5 > message delivery contracts and starts the tx appropriately with just > the WorkManager implemented. I did this with the JBoss 4.0 jca 1.5 > support testcases until I wrote the jca 1.5 deployment stuff. I.e., > don't use actual jms, just fake the message delivery part of an adapter. > > BTW my opinion ATM is that mdbs don't need an instance pool, the jca > 1.5 inbound adapter does that work. All you need is to create > MessageEndpoints as requested up to the maximum number you want... > > /********************************** > * David Jencks > * Partner > * Core Developers Network > * http://www.coredevelopers.net > **********************************/ > > > On Thursday, September 25, 2003, at 11:51 PM, Richard Monson-Haefel > wrote: > >> On 9/25/03 12:23 PM, in article >> F5B100B7-EF7C-11D7-9F7C-000A959D0312@yahoo.co.uk, "James Strachan" >> wrote: >>> >>> Once we can deploy stateless SBs then I'd have thought doing MDBs >>> should be similar yes? Basically I was just gonna do something >>> extremely simple for now - write a dummy little JMS subscriber MBean >>> that can mock the JCA connection manager until the JCA part is ready, >>> and then get some MDBs working. Then folks could try hooking the mail >>> stuff into the same MDB service. >>> >>> So does this all sound like a reasonable plan? Anyone working on this >>> stuff or on the EJB side of things care to correct any of my mistaken >>> assumptions. >> >> I'm pretty sure that your stop-gap solution won't work because I >> worked on >> this problem almost exactly two years ago - before JCA 1.5. The >> following >> explains the problem with using the JMS API as a "moch" connector for >> Message Driven Beans. It's kind of complicated.