Why don't you get the responses sent to your test?
The test can then wait for all responses or timeout.
Regards,
Adrian
On Fri, 2003-09-26 at 13:30, Stefan Puiu wrote:
> Hello Adrian and thanks for the suggestion,
>
> the point is the use case is 100% asynchronous, the JMS client is
> supposed to do other things and get notified when a reply comes. The
> processing that the MDB on the other side is doing is quite lengthy
> also, so this and the nature of the use case made us choose this
> pattern. On the other hand, in my tests (and only there) I want a
> synchronous behaviour because otherwise it would be a problem if I'd
> have to run say 5 test methods - the first method is run, it completes,
> the second method runs, then the reply the listener waits for arrives,
> and the two things go in parallel, I think it's kind of messy. On the
> other hand if the reply fails that won't show up in the JUnit reports,
> since the processing of replies isn't done in the JUnit process but in
> the listener onMessage method.
>
> What I would want to have is a test class in which I have a number of
> testXXX methods that can be run one after another, so that testXXX2 runs
> after the whole message cycle triggered by testXXX1 completes.
>
> Adrian Brock wrote:
>
> >The answer to your specific question is something like
> >the following in jboss.xml:
> >
> > <enterprise-beans>
> > <entity>
> > <ejb-name>CMRTreeBean</ejb-name>
> >
> ><local-jndi-name>java:/cmrTransactionTest/TreeLocal</local-jndi-name>
> > <method-attributes>
> > <method>
> > <method-name>get*</method-name>
> > <read-only>true</read-only>
> > </method>
> > <method>
> > <method-name>isIdentical</method-name>
> > <read-only>true</read-only>
> > </method>
> > </method-attributes>
> > </entity>
> >
> >
> >I don't recommend this pattern, there is little point introducing
> >JMS when you really have a synchronous process. In fact it will perform
> >much worse, besides a host of other problems you might face.
> >
> >If the response message went back asynchronously to the client,
> >then it might be worth it.
> >
> >Regards,
> >Adrian
> >
> >On Thu, 2003-09-25 at 16:57, Stefan Puiu wrote:
> >
> >
> >>Hello,
> >>
> >>I'm using JBoss 3.2.1, the 1.4.2 Sun JDK on Mandrake Linux 9.1.
> >>
> >>I have some test classes that need to send messages on a JMS queue and
> >>expect an answer on another queue. I also read some information from a
> >>database that I use to build the messages (namely, it's a getter
> >>method). Now, I cannot send the messages on the first queue and then use
> >>a blocking receive() to wait for replies, because that would cause an
> >>application deadlock. The cause for the deadlock, as far as I could
> >>understand, was that the testXXX method that would send the message was
> >>wrapped in a transaction (the test class inherits from EJBTestCase from
> >>JUnitEJB, which wraps all calls to testXXX methods, together with the
> >>setUp and tearDown methods, in a single transaction). When a MDB of mine
> >>would also need to read the info from the database, there would be a
> >>problem, because the first transaction wouldn't have committed yet (it
> >>would commit when receiving the message). The test class wasn't
> >>modifying the database, it would just look up a value (using a
> >>findByName method), so the situation was rather stupid. That's how the
> >>method is defined in the module ejb-jar.xml:
> >>
> >> <query-method>
> >> <method-name>findByName</method-name>
> >> <method-params>
> >> <method-param>java.lang.String</method-param>
> >> </method-params>
> >> </query-method>
> >> <ejb-ql><![CDATA[
> >> SELECT OBJECT(c)
> >> FROM Profile c
> >> WHERE c.name=?1
> >>
> >> ]]></ejb-ql>
> >> </query>
> >>
> >>And in my test class I do something like this:
> >>
> >> pHome = (ProfileHome) jndi.lookup ("ca/ProfileEJB");
> >> Profile profile = null;
> >> try {
> >> profile = (Profile) pHome.findByName("CA_Cert").toArray() [0];
> >> }
> >> catch (javax.ejb.FinderException fe) {
> >> throw new RuntimeException (fe);
> >> }
> >> profileId = profile.getValueObject().id;
> >>
> >>For now I've made this go away by making the test class inherit from
> >>MessageListener and make it listen for replies, but this is kind of ugly
> >>since JUnit reports success when sending the message has completed, and
> >>it also makes it hard to have more than one test method in that class.
> >>How can I solve this? I think there was something on setting certain
> >>methods read-only on the O'Reilly site, but I don't have the link
> >>anymore. What would be a good way to run these kinds of tests? Would
> >>altering method settings for the findByName method suffice?
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>JBoss-user mailing list
> >>[EMAIL PROTECTED]
> >>https://lists.sourceforge.net/lists/listinfo/jboss-user
> >>
> >>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
--
xxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
