Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <003001c28029$556ce6d0$0200a8c0@spiritsoft.com>
From: "James Strachan" <james_strachan@yahoo.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <017601c2800f$b51bfbd0$b4c8c8c8@octovma>
Subject: [jelly][cactus] embedding servlet engines and integration testing...
 (was Re: cvs commit:
 jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/jetty/docRoot
 test1.txt)
Date: Wed, 30 Oct 2002 15:30:51 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Vincent Massol" <vmassol@octo.com>
>
> Looks very cool. Would it be possible for someone to show an example of
> how it works?

Here's a simple example in this directory...

http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jelly/src/test/org/apa
che/commons/jelly/jetty/

such as

http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jelly/src/test/org/apa
che/commons/jelly/jetty/jellyResourceHandler.jelly?rev=HEAD


> In cactus we have a JettyInitializer class that we use to start an
> embedded Jetty server in the junit test suite.
>
> Is that the same thing?

Very close yes. Right now the Jetty-Jelly tags create an embedded Jetty
server which can be used with inside unit test. Right now the tags have
focussed on generating mock responses or invoking a Jelly script to process
the response. (So mocking the server). However it should be pretty easy to
add real registrations of servlets or deployments of wars etc.


> The philosophy of Cactus is that there is an engine (the cactus
> framework) and several front ends. ATM Cactus has the following front
> ends:
> - Maven plugin
> - Jetty integration in IDE using the JettyInitializer class I mentioned
> - Eclipse plugin (in development)
> - Ant integration
>
> I am completely in favor of adding a Jelly Cactus Tag library. In other
> words, we could factor out the Cactus Maven plugin (already using jelly)
> and create a Cactus tag suite that the Cactus Maven plugin would then
> use.

Sounds cool

> ATM, in all the Cactus plugins we have had to create ways to start/stop
> servers as there is no general library available for this. However, I am
> quite keen to start using someone else's as this is not the business of
> Cactus to develop ways to start/stop/deploy applications in containers.
>
> What do you think?

Funnily enough only yesterday as part of my day job I was creating some
integration tests using Jelly and JellyUnit. I was sending a bunch of JMS
messages around a system, waiting for a while, then testing that the
database contained the right information inside it. The tests are fine
though the big missing pieces are

* start/stop/redeploy

Having some simple way to deploy WARs, EARs, MDBs and so forth, on remote
testing machines as part of a test sounds like a great idea, then being able
to undeploy them after the test has finished. Are there Ant tasks we can
reuse for this?

* orchestration and coordination.

Right now I use the <interaction:ask> tag to pause the integration tests
until the right point before the database-tester kicks off. Ideally that
should be automated. So I'd like some way to orchestrate the integration
tests so I can totally automate things. So this could be where we get to use
Werkflow & Jelly to perform cross-process coordination to allow the (say)
database tests to run once the input messages have been fully processed.
Then we can use JMS, JMX, HTTP or SOAP requests to signal when to start/stop
testing activities.

Getting back to your original point; yes I could do with a simple way to
start/stop/deploy artifacts. Would the existing Ant tasks out there do the
trick?

James
-------
http://radio.weblogs.com/0112098/

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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