jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: HTTPUnit Integration
Date Sat, 31 Aug 2002 18:16:33 GMT
Hi Richard,

It is a bug that was introduced when Cactus switched to using HttpClient
in version 1.4. I have fixed it in Cactus 1.4.1 that I will try to
deliver later today.

I have also added the HttpUnit test to the Cactus test suite (I had
wanted to do that a while ago but somehow I had some issues and then I
forgot about it).

Thanks
-Vincent

> -----Original Message-----
> From: Hirsch Richard [mailto:richard.hirsch@siemens.com]
> Sent: 26 August 2002 12:55
> To: 'Cactus Users List'
> Subject: AW: HTTPUnit Integration
> 
> Hi Vincent,
> 
> I am using the TestServletTestCase_HttpUnit.java from the Cactus
release.
> The class works in the Tomcat 4.0 but in our environment which
includes
> Tomcat 3.2.3 and Jboss 2.4.3, it fails. When I tried writing my own
endXXX
> method with the cactus Webresponse object it worked but one with the
> httpunit Webresponse object kept returning an empty response.
> 
> One of the advantages of both being in Europe is the fast email
> turn-around....
> 
> Another question: why didn't you include the httpunit unit test in the
> Alltests class? Since the httpunit jar is already in the distribution,
you
> could include the tidy.jar as well.
> 
> Thanks,
> 
> Dick
> 
> -----Ursprungliche Nachricht-----
> Von: Vincent Massol [mailto:vmassol@octo.com]
> Gesendet: Montag, 26. August 2002 13:20
> An: 'Cactus Users List'
> Betreff: RE: HTTPUnit Integration
> 
> 
> Hi Richard,
> 
> Your test does indeed return the correct string in the HTTP response :
> 
> > 12:58:19,339 [main] INFO  httpclient.wire                 - <<
> "something
> > to
> > return for the test"
> 
> The <webresult></webresult> simply means to Cactus that there were no
> error while executing the tests. Cactus does 2 call for each test, one
> call to execute the test and another one to get the result of the
test,
> i.e. ok or not ok (if not ok, it gets the exception).
> 
> Thus, your test did succeed on the server side. The problem is on the
> client side. Could you send your endHttpUnitGetText() method ?
> 
> Thanks
> -Vincent
> 
> > -----Original Message-----
> > From: Hirsch Richard [mailto:richard.hirsch@siemens.com]
> > Sent: 26 August 2002 12:08
> > To: 'Cactus Users List'
> > Subject: HTTPUnit Integration
> >
> > I'm having some trouble integrating httpunit into my cactus
> environment.
> > We
> > are using Tomcat 3.2.3. Could that be my problem? I am getting an
> empty
> > WebResponse.  I am using the testHttpUnitGetText class from the
cactus
> > distribution (jakarta-cactus-13-1.4) as well as the other
> jars(httpunit,
> > jnuit, etc.)
> >
> > Notice that the httpclient.wire method has the correct value but the
> > <webresult> element is empty ("<webresult></webresult>").
> >
> > Thanks,
> >
> > Dick
> >
> > Here is the log4j trace:
> >
> > 12:58:17,876 [main] DEBUG n.TestServletTestCase_HttpUnit  -
> -------------
> > Test: testHttpUnitGetText
> > 12:58:18,017 [main] DEBUG httpclient.HttpClient           -
> > HttpClient.startSession(String,int,boolean): Host:localhost
Port:8080
> > HTTPS:false
> > 12:58:18,037 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.HttpConnection
> > 12:58:18,037 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.open()
> > 12:58:19,178 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.execute(HttpState,HttpConnection)
> > 12:58:19,178 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.execute(): looping.
> > 12:58:19,178 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.writeRequest(HttpState,HttpConnection)
> > 12:58:19,188 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.writeRequestLine(HttpState,HttpConnection)
> > 12:58:19,188 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,188 [main] INFO  httpclient.wire                 - >> "GET
> >
>
/webesa/ServletRedirector?Cactus_TestMethod=testHttpUnitGetText&Cactus_T
> es
> > tC
> >
>
lass=com.db.cfc.test.app.gen.TestServletTestCase_HttpUnit&Cactus_Automat
> ic
> > Se
> > ssion=true&Cactus_Service=CALL_TEST HTTP/1.1
> > "
> > 12:58:19,188 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
> > 12:58:19,298 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,298 [main] INFO  httpclient.wire                 - >>
> > "Content-type: application/x-www-form-urlencoded
> > "
> > 12:58:19,298 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,298 [main] INFO  httpclient.wire                 - >>
"Host:
> > localhost
> > "
> > 12:58:19,298 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,298 [main] INFO  httpclient.wire                 - >>
"User-
> > Agent:
> > Jakarta HTTP Client/2.0.0a1
> > "
> > 12:58:19,298 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.writeLine()
> > 12:58:19,298 [main] INFO  httpclient.wire                 - >> \r\n
> > 12:58:19,298 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readResponse(HttpState,HttpConnection)
> > 12:58:19,298 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readStatusLine(HttpState,HttpConnection)
> > 12:58:19,298 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,339 [main] INFO  httpclient.wire                 - <<
> "HTTP/1.0
> > 200
> > OK" [\r\n]
> > 12:58:19,339 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readResponseHeaders(HttpState,HttpConnection)
> > 12:58:19,339 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,339 [main] INFO  httpclient.wire                 - << "Set-
> > Cookie2:
> > JSESSIONID=3p9gsn38l1;Version=1;Discard;Path="/webesa"" [\r\n]
> > 12:58:19,339 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,339 [main] INFO  httpclient.wire                 - << "Set-
> > Cookie:
> > JSESSIONID=3p9gsn38l1;Path=/webesa" [\r\n]
> > 12:58:19,339 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,339 [main] INFO  httpclient.wire                 - <<
> > "Servlet-Engine: Tomcat Web Server/3.2.3 (JSP 1.1; Servlet 2.2; Java
> > 1.3.1_04; Windows 2000 5.0 x86; java.vendor=Sun Microsystems Inc.)"
> [\r\n]
> > 12:58:19,339 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,339 [main] DEBUG httpclient.Cookie               -
> > Cookie.parse():
> > Adding cookie - JSESSIONID=3p9gsn38l1; $Path=/webesa
> > 12:58:19,339 [main] DEBUG methods.GetMethod               -
> > GetMethod.readResponseBody(HttpState,HttpConnection)
> > 12:58:19,339 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readResponseBody(HttpState,HttpConnection)
> > 12:58:19,339 [main] INFO  httpclient.wire                 - <<
> "something
> > to
> > return for the test"
> > 12:58:19,339 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.execute(): closing connection since we're using
> HTTP/1.0
> > 12:58:19,339 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.close()
> > 12:58:19,339 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.closeSocketAndStreams()
> > 12:58:19,349 [main] DEBUG httpclient.HttpClient           -
> > HttpClient.startSession(String,int,boolean): Host:localhost
Port:8080
> > HTTPS:false
> > 12:58:19,349 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.HttpConnection
> > 12:58:19,349 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.open()
> > 12:58:19,359 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.execute(HttpState,HttpConnection)
> > 12:58:19,359 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.execute(): looping.
> > 12:58:19,359 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.writeRequest(HttpState,HttpConnection)
> > 12:58:19,359 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.writeRequestLine(HttpState,HttpConnection)
> > 12:58:19,359 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,359 [main] INFO  httpclient.wire                 - >> "GET
> > /webesa/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
> > "
> > 12:58:19,359 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
> > 12:58:19,359 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,359 [main] INFO  httpclient.wire                 - >>
> > "Content-type: application/x-www-form-urlencoded
> > "
> > 12:58:19,359 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,359 [main] INFO  httpclient.wire                 - >>
"Host:
> > localhost
> > "
> > 12:58:19,359 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.write(byte[])
> > 12:58:19,359 [main] INFO  httpclient.wire                 - >>
"User-
> > Agent:
> > Jakarta HTTP Client/2.0.0a1
> > "
> > 12:58:19,359 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.writeLine()
> > 12:58:19,359 [main] INFO  httpclient.wire                 - >> \r\n
> > 12:58:19,359 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readResponse(HttpState,HttpConnection)
> > 12:58:19,359 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readStatusLine(HttpState,HttpConnection)
> > 12:58:19,359 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,369 [main] INFO  httpclient.wire                 - <<
> "HTTP/1.0
> > 200
> > OK" [\r\n]
> > 12:58:19,369 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readResponseHeaders(HttpState,HttpConnection)
> > 12:58:19,369 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,379 [main] INFO  httpclient.wire                 - <<
> > "Servlet-Engine: Tomcat Web Server/3.2.3 (JSP 1.1; Servlet 2.2; Java
> > 1.3.1_04; Windows 2000 5.0 x86; java.vendor=Sun Microsystems Inc.)"
> [\r\n]
> > 12:58:19,379 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.readLine()
> > 12:58:19,379 [main] DEBUG methods.GetMethod               -
> > GetMethod.readResponseBody(HttpState,HttpConnection)
> > 12:58:19,379 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.readResponseBody(HttpState,HttpConnection)
> > 12:58:19,379 [main] INFO  httpclient.wire                 - <<
> > "<webresult></webresult>"
> > 12:58:19,379 [main] DEBUG httpclient.HttpMethod           -
> > HttpMethodBase.execute(): closing connection since we're using
> HTTP/1.0
> > 12:58:19,379 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.close()
> > 12:58:19,379 [main] DEBUG httpclient.HttpConnection       -
> > HttpConnection.closeSocketAndStreams()
> > 12:58:19,429 [main] DEBUG n.TestServletTestCase_HttpUnit  -
Exception
> in
> > test
> > junit.framework.AssertionFailedError: expected:<something to return
> for
> > the
> > test> but was:<>
> > 	at junit.framework.Assert.fail(Assert.java:51)
> > 	at junit.framework.Assert.failNotEquals(Assert.java:234)
> > 	at junit.framework.Assert.assertEquals(Assert.java:68)
> > 	at junit.framework.Assert.assertEquals(Assert.java:75)
> > 	at
> >
>
com.xxx.xxx.test.app.gen.TestServletTestCase_HttpUnit.endHttpUnitGetText
> (U
> > nk
> > nown Source)
> > 	at java.lang.reflect.Method.invoke(Native Method)
> > 	at
> >
>
org.apache.cactus.AbstractWebTestCase.callEndMethod(AbstractWebTestCase.
> ja
> > va
> > :177)
> > 	at
> >
>
org.apache.cactus.AbstractWebTestCase.runGenericTest(AbstractWebTestCase
> .j
> > av
> > a:263)
> > 	at
> > org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:133)
> > 	at
> >
org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:195)
> > 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> > 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> > 	at junit.framework.TestResult.run(TestResult.java:109)
> > 	at junit.framework.TestCase.run(TestCase.java:131)
> > 	at junit.framework.TestSuite.runTest(TestSuite.java:173)
> > 	at junit.framework.TestSuite.run(TestSuite.java:168)
> > 	at
> >
>
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe
> st
> > Ru
> > nner.java:325)
> > 	at
> >
>
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitT
> es
> > tR
> > unner.java:524)
> >
> > -----Ursprungliche Nachricht-----
> > Von: Vincent Massol [mailto:vmassol@octo.com]
> > Gesendet: Montag, 26. August 2002 12:15
> > An: 'Cactus Users List'
> > Cc: 'Oliver Rossmueller'
> > Betreff: RE: JUnitEE and Cactus
> >
> >
> > Hi Oliver,
> >
> > > -----Original Message-----
> > > From: Oliver Rossmueller [mailto:oliver@oross.net]
> > > Sent: 25 August 2002 15:50
> > > To: Vincent Massol
> > > Subject: JUnitEE and Cactus
> > >
> > > Hi Vincent,
> > >
> > > finally I could find some time to check out the latest release of
> > > Cactus, so here are from my point of view the advantages and
> > > disadvantages of JUnitEE and Cactus:
> > >
> > >
> > > Advantages of JUnitEE
> > >
> > > - no special requirements to test case classes -
> > > junit.framework.TestCase as superclass is enough
> >
> > ok. The only reason for having to extend a given test class (on the
> > server side) is to easily pass the servlet objects (request,
response,
> > etc) to the test. How is this done by JUnitEE? By calling some
static
> > class? The TestCase could also be wrapped but then the user will
have
> to
> > perform a cast to access the additional features.
> >
> > > - as simple as possible: write your tests, package them in a WAR
> with
> > > JUnit and JUnitEE, deploy the WAR and start your tests from your
> > browser
> >
> > Actually this is also exactly the lifecycle with Cactus if you want
to
> > test from your browser. If you want to test with your IDE, Ant, etc,
> > simply use *any* existing test runner (including JUnitEE ! :-))and
off
> > you go.
> >
> > >
> > > Disadvantages of JUnitEE
> > >
> > > - requires special Ant task which does the client/server
> communication
> >
> > Does JUnitEE already provides this? It didn't last time I looked. If
> it
> > now does, then Cactus and JUnitEE are now really the same, as this
is
> > what is done in Cactus :-). Another reason to merge ... :)
> >
> > >
> > >
> > > Advantages of Cactus
> > >
> > > - no special Ant integration is necessary as the junit task will
> also
> > > run Cactus test cases (the client/server communication is
> encapsulated
> > > in the test case itself)
> >
> > yep
> >
> > > - testing of servlet output is easy because of httpunit
integration
> >
> > yep
> >
> > >
> > > Disadvantages of Cactus
> > >
> > > - configuration of client-side cactus.properties
> >
> > yes and no. cactus.properties is optional. However, you still need
to
> > tell Cactus what URL it should call to find its redirector (that's
the
> > only piece of information that is required). Note that this is not
> > needed if you're running your test from a browser.
> >
> > > - requires special test case super class
> >
> > yep. Not sure this is really a problem though. Do you have an issue
in
> > mind ?
> >
> > > - servlet test runner produces xml which is displayed in a useful
> > manner
> > > in IE only; for other browsers a transformation to html would be
> > > required but would also require xerces/xalan in the WAR
> >
> > yes, you're right. I would be +1 to offer an HTMLFormatter class in
> > addition to the XMLFormatter one that exist for users who do not use
a
> > browser that can display XML *and* that cannot do XSLT
transformation.
> > That's one of the things JUnitEE could bring should we agree to
merge
> > ... :-)
> >
> > >
> > >
> > > I was thinking about how to integrate the two projects. The most
> > > important aspect of JUnitEE is it's simplicity and ability to run
> test
> > > cases of any kind inside the servlet container.
> >
> > Can you write taglib tests with JUnitEE? Can you write Filter tests
> too?
> >
> > > To get the same out of
> > > Cactus would mean to remove client/server communication from the
> test
> > > case.
> >
> > Not true :-) Cactus already provides this. The tomcat integration
> > tutorial (http://jakarta.apache.org/cactus/howto_tomcat.html) shows
> that
> > you don't have to care about the client/server communication at all.
> >
> > > This is a big change of Cactus' architecture and would require a
> > > complete rework and would probably break existing Cactus-based
test
> > > cases. So I don't think you would like to go this way.
> >
> > I don't understand. Can you please give me more details?
> >
> > >
> > > The only realistic way in cooperation that would make sense for me
> is
> > > for you to use JUnitEE as the servlet test runner instead of
writing
> > > your own one. So you could benefit from the development of JUnitEE
> and
> > > concentrate on the core features of Cactus. For example I could
> extend
> > > JUnitEE to produce xml output as your test runner does. I was
> already
> > > thinking about using xml for the communication with the ant task,
so
> I
> > > might do it anyway.
> > >
> >
> > Ok. Here is my point of view:
> >
> > - I think this niche of in-container unit testing is too small for
> > having 2 projects
> > - You mentioned an Ant taks for JUnitEE to communicate with the
server
> > side. This is exactly the same as Cactus. This means that JUnitEE
and
> > Cactus become competitors (they are on the same domain).
> > - I believe it is *way* better to join our forces and make something
> > better for our users than each separate project. You are working
alone
> > on JUnitEE and I am working almost alone on Cactus. Let's join
forces!
> > There are still lots of things to do to improve integration unit
> testing
> > :
> >    - EJB redirectors including MDB redirector for unit testing MDBs
> >    - Bundling Cactus/JUnitEE with application server containers to
> make
> > them a de facto standard.
> >    - Write IDE plugins to make it even easier. I have started a
Maven
> > plugin for Cactus and I am currently learning plugin development in
> > Eclipse in order to write a Cactus plugin
> >
> > > You mentioned  some plugins you would like to create for Cactus.
> Could
> > > you be a little bit more specific in this point and also in what
> your
> > > plans for Cactus are?
> >
> > See above. You can also get some ideas by looking at the todo list :
> > http://jakarta.apache.org/cactus/howto_tomcat.html
> >
> > In addition, there may be another new area of testing that could be
> > interesting (that's for more longer term) : "Stress Unit Testing"
(TM)
> > :-)
> >
> > Persons who write server side applications are usually writing them
to
> > support heavy loads and would be very interested to know how some
> > specific methods handle the load (and test thread handling). Ok,
there
> > are lots of issues to discuss and I'm not even sure it could work
but
> > that's an idea.
> >
> > Moreover there are persons who have started extensions to Cactus for
> > providing even further ease of testing for specific frameworks. An
> > example is the StrutsTestCase project for unit testing Struts
actions.
> >
> > I am also currently integration Jetty completely into Cactus as a
> Cactus
> > extension. You may know that Jetty is a very fast embeddable servlet
> > engine. It is working on my machine (I haven't committed it yet) and
> the
> > net result is that I can now start servlet/filter/JSP tests without
> > having to create a WAR and deploying it! Ok, it won't fit all
> scenarios
> > but it is a *very* fast way to unit test your code in a container!
> Jetty
> > starts in 350 ms ! Here is how you can use it:
> >
> > <junit>
> >   <classpath>
> >     cactus
> >     jetty jar
> >   </classpath>
> >
> >   my tests
> > </junit>
> >
> > That's the minimum you need! Nothing more, no config files, etc.
> >
> > I would view this method as very useful when you're inside your IDE
> and
> > writing your code. As soon as you have finished one method, you
right
> > click on your test and use the IDE JUnit integration and click "run"
> and
> > it starts in 350 ms and run your test. Wow! Then as a second step
you
> > would automate running the tests in Ant for example using your real
> > container, and you would run these tests less often (for example
every
> > few hours or once very day).
> >
> > > I have also some points on my list for the next
> > > release of JUnitEE:
> > >
> > > - allow to run a single test out of a test suite; this is very
> helpful
> > > for debugging and is the most important feature I'm missing in
> JUnitEE
> > > at the moment
> >
> > yes. Good idea :-)
> >
> > > - create a servlet/jsp which displays all test suites and tests
> > > available so you can select the suites and tests you would like to
> run
> > > in the browser in a user-friendly way
> >
> > another good idea ...
> >
> > > - flush mode of the test runner so you get immediate feedback
while
> > the
> > > tests are running and don't have to wait until all tests are
> finished
> > to
> > > see the results
> >
> > yes that would be nice ...
> >
> > >
> > > That's it for the moment. Perhaps when I know more about your
plans
> > and
> > > ideas we will find other possibilities to cooperate, at the moment
I
> > can
> > > only see the way mentioned above.
> > >
> >
> > Oliver, I really think we should merge and bring all these wonderful
> > ideas together.
> >
> > Tell me what you think
> >
> > Thanks
> > -Vincent
> >
> > > Greetings
> > > Oliver
> > >
> > >
> > > Vincent Massol wrote:
> > >
> > > >Hi Oliver,
> > > >
> > > >Good to see that someone as taken the lead on JUnitEE! I am
working
> > on
> > > >Cactus and in version 1.4, Cactus has added a ServletTestRunner
in
> > > >addition to supporting all the existing JUnit Test Runner.
> > > >
> > > >I have to say that although Cactus has a strong community of
users,
> I
> > am
> > > >the only person really leading the Cactus project and I'm really
> > looking
> > > >for synergies/help/partners/etc.
> > > >
> > > >I think Cactus and JunitEE are doing very very similar things now
> and
> > > >that Cactus is now as easy to use as JUnitEE (If not, that's one
> > subject
> > > >we could work on! :-)). I would be very happy to integrate any
> > JUnitEE
> > > >feature that you would like to bring ... ;-)
> > > >
> > > >I think, this domain of integration unit testing is very small
and
> we
> > > >could benefit from mutual help. There are still nice things to do
> ...
> > > >like the EJB Redirector stuff ...
> > > >
> > > >Would you be open to discuss this ?
> > > >
> > > >Thanks a lot
> > > >-Vincent
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: junitee-user-admin@lists.sourceforge.net
> [mailto:junitee-user-
> > > >>admin@lists.sourceforge.net] On Behalf Of Oliver Rossmueller
> > > >>Sent: 15 August 2002 21:59
> > > >>To: junitee-user@lists.sourceforge.net
> > > >>Subject: [junitee-user] Release 1.4
> > > >>
> > > >>Release 1.4 of JUnitEE is available for download at
> > > >>http://sourceforge.net/project/showfiles.php?group_id=31476
> > > >>
> > > >>Changes:
> > > >>------------
> > > >>- New option to run all tests found in a specified jar file
> > > >>- Ant task for build integration
> > > >>- TestServletBase is no longer abstract and should work as is
> > > >>- Bug Fixes (Bug 583856, 583859)
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:cactus-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:cactus-user-help@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:cactus-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:cactus-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>


Mime
View raw message