When cactus has mdb support, I'll be re-factoring my tests to use cactus as
I'm mightily impressed with the work I saw. Cactus looks like "The Right
Thing To Do"(TM)
Roger
"Vincent Massol"
<[EMAIL PROTECTED] To: "'Cactus Users List'"
<[EMAIL PROTECTED]>
com> cc:
Subject: RE: MDB Testing
08/08/2004 11:43
Please respond to
"Cactus Users
List"
... I wish Cactus could have helped you... but unfortunately MDB support is
not there yet...
-Vincent
> -----Original Message-----
> From: Roger Day [mailto:[EMAIL PROTECTED]
> Sent: jeudi 5 ao�t 2004 10:29
> To: Cactus Users List
> Cc: Cactus Users List
> Subject: RE: MDB Testing
>
>
>
>
>
>
> I am creating a build scheduler using Jboss, JMS and MDBs. After some
> dalliance with cactus - I spent a long time finding out that MDBs
weren't
> supported then mockobjects (at first I didn't want to resort to hauling
up
> Jboss for every test) but then we realised that we were doing
"integration
> testing" so that mockobjects didn't really have a place in this scheme. I
> would of liked to have used Cactus - I spent a long time faking up code
to
> stop and start Jboss - but it's not turned out too bad.
>
> I now use standard Junit testing with Jboss. Jboss has a nice feature
> where
> you can just copy MDBs directly into the deployment area of Jboss. Each
> MDB
> test has a send queue (for the MDB) and a receive queue (for results
> coming
> back). Although, sometimes I don't use the receive queue - as part of my
> tests I split off a SOAP server (written in Perl) - from which I can also
> poll results.
>
> Very soon, I'm going to insert Quartz into the environment and get it to
> pass build messages to the receiving queue, whilst I use another queue to
> receive results.
>
> Hope this helps
>
> Roger.
>
>
>
>
> "Mark Lybarger"
> <[EMAIL PROTECTED] To: "Cactus
> Users List" <[EMAIL PROTECTED]>
> panies.com> cc:
> Subject: RE: MDB
> Testing
> 04/08/2004 16:47
> Please respond to
> "Cactus Users List"
>
>
>
>
>
>
> cactus does provide the ability to test ejb's (stateless/statefull
session
> ejb's, entity ejb's). it can do this easily b/c the calls are
syncronous.
>
> mdb's are a horse of a different color. the client posts a message to
> topic/queue and then sometime later, the mdb gets it and processes it.
> it's not a make a call, get a response, check the response type of thing.
> for us, our mdb's are merely pass through calls onto stateless session
> ejb's which do the "business" work.
>
> i would be interested in hearing how others are doing automated testing
> their actual mdb's though.
>
>
> > -----Original Message-----
> > From: David Plass [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 04, 2004 8:51 AM
> > To: Cactus Users List
> > Subject: RE: MDB Testing
> >
> >
> > With apologies to Vincent, why do you need Cactus to test MDBs?
> >
> > MDBs don't require a servlet container (which is what Cactus
> > provides). You
> > can just use Junit with an
> > appropriately defined jndi.properties file that points at your EJB
> > container.
> >
> > --DP
> >
> >
> > -----Original Message-----
> > From: Srinivas Sindhey [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 04, 2004 1:00 AM
> > To: [EMAIL PROTECTED]
> > Subject: MDB Testing
> >
> >
> > Hi Friends,
> > Has any one tested MDB's through CACTUS? If yes, could some
> > one tell me how
> > do i go about it.
> >
> > Thanks
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
