> -----Original Message----- > From: Christian Sell [mailto:[EMAIL PROTECTED] > Sent: vendredi 7 janvier 2005 16:10 > To: Cactus Users List > Cc: [EMAIL PROTECTED] > Subject: Re: AppServerUnit and Cactus > > >>not exactly. ASU offers 2 redirectors (I call them invokers): a simple > >>servlet-based web interface and a J2EE application client. The latter is > >>convenient for integration into Ant scripts, which in fact was the first > >>incentive for implementing ASU. > > > > > > Please have a look at > http://jakarta.apache.org/cactus/how_it_works.html. > > The redirector is the server side interceptor that starts the unit tests > on > > the server side. > > > > For example, imagine that you have a test that tests a local session > bean. > > As you cannot access it from the client side you need what I call a > > redirector (aka interceptor) located on the server side. > > > > This is independent of the test is started (whether from Ant, Maven, a > web > > page, etc). > > ok, it seems we indeed have some clarification to do here. I mixed up > terminology in my last mail. Heres my next try: > > ASU has only one "redirector", namely a session bean > (TestRunnerSession). TRS is essentially called from the TestRunnerClient > with the following parameters (semantics as usual): > > - test case class name > - test case method name (optional) > > TRS then instantiates the test case and invokes it, using the standard > JUnit machinery (with the exception of some hacky extensions that make > the test result serializable). The test result is passed back to the > calling client.
Ok, that's the way it's done too in Cactus land. We were also thinking about serializing the test case instance instead of instantiating it on the server side. The reason is that instantiating it on the server side prevents the user from calling user-defined constructors on the test class instance. But we've not done that yet. > > To invoke the TRS, there are 2 clients available (which I call > invokers), both of which are automatically packaged with the ear by the > ant task: > > - an application client invoker > - a web application (servlet) invoker. > > > Yep, exactly. What I was just saying is that Cactus has several > redirectors > > (servlet, jsp, filters) which all offer entry points into the server. > > I think a session bean is a better choice for the redirector, as it > gives you (me) the option of using the application client as an invoker, > which makes a direct remote call to the TRS. Ok. For Cactus it is not a question of better choice. We have to. For testing JSP taglibs, we have to provide taglibs container objects to the test case, for testing the Servlet API, we have to provide servlet container object and same for filters. We have been discussing providing an EJB redirector in the past (using a SessionBean and an Entity Bean) in order to also provide ejb container objects but we have not done it yet (even though we had started in a branch and several persons have also contributed some code for this). So today, to test EJBs, the user can use the Servlet redirector (by extending ServletTestCase or using a ServletSuite) or any other redirector. > > >>There is also an option to execute tests in "client mode", i.e. in the > >>context of the redirector/invoker. > > > > > > Not sure I get this one... ;-) > > if you have a test case that makes remote calls to server side > components, you can execute it "in front of" the TRS (the TRS is not > used). This makes mostly sense if you use the application client invoker This is a plain JUnit test, right? [snip] It seems to me we are really following the same route. The main difference is that Cactus has started with the Servlet/Filter/Taglibs components first and has moved to EJB later in his history whereas ASU has started with EJBs. So, ASU is probably more advanced in the ear-ification step. It seems to me Cactus is also a superset of ASU. Do you have a roadmap for ASU's future? BTW, are you aware of JUnitEE? I'll add a news item mentioning ASU in Cactus news area on the web site. Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
