Howdy folks, [some of this has been discussed on IRC, I'm trying to summarize here]
Vincent Massol wrote:
1/ The interface must provide all needed parameters to the implementation classes. ATM there are no parameters passed which makes virtually impossible to provide an implementation. The Tomcat implementation is "cheating" :-) as it is using hardcoded values.
>
If you view the IContainerProvider interface as an extension point exposed by the Cactus plug-in, implementations of the interface are potentially (and mostly) Eclipse plug-ins themselves. Thus, they should have their own means of getting their configuration.2/ As a consequence of 1/ there should be a class containing all container information (such as ContainerInfo or ContainerDetail): - home directory - port to use - arbitrary parameters
What is passed into the IContainerProvider.start() should be parameters that are *needed* for communication between the Cactus plug-in and the container provider plug-ins. One such parameter is the contextURL -- the container is required to listen to the same port that Cactus is sending the test requests to, same with the context path if we don't want to hard-wire that.
The home directory, OTOH is completely up to the container provider. A container provider plug-in that provides an embedded servlet container (such as Jetty) can do without a home directory. Others can ask the user about the home directory in a preference page, for example. Most importantly, the Cactus plug-in itself does not need to know about the home directory, so it makes little sense to make it find out and later pass the information to the container provider. The same argument can be applied for arbitrary (i.e. container-specific) parameters.
I think we need to get the concepts clear here. What I was proposing with a IContainerProvider extension point was to separate two concerns:
- decorating the JUnit plugin so that Cactus test cases can be run
- providing a container in which the Cactus test cases can be run
The Cactus plug-in would take over responsibility for the first concern: it hooks into some aspects of the JUnit plugin, to:
- provide the cactus.contextURL property
- package the components to deploy to container (war or ear)
- start the container before running the tests, stop the container
after the tests have completed
Because the last responsibility in that list is quite complex in reality, we want to delegate that to implementors of the IContainerProvider extension point. Their responsiblities would be:
- they *know* *how* to start/stop a concrete container, and do that
when the Cactus plug-in requests them to
- they also know how to deploy/redeploy components (webapps for now)
to the container, and do that when the Cactus plug-in requests them
to
Now, to take advantage of the existing Ant scripts in Cactus's sample-servlet, the Cactus plug-in would actually come with an implementation of the IContainerProvider interface. That implementation might be called GenericAntContainerProvider, and it would have to be able to delegate all tasks to the corresponding Ant scripts/targets.
3/ The API should be modified to include needed parameters:
void start(ContainerInfo info) throws CoreException;
void deploy(String contextPath, URL deployableObject(war or ear),
Credential credentials) throws CoreException;
void undeploy(String contextPath, Credential credentials) throws
CoreException;
void stop(ContainerInfo info) throws CoreException;
where Credential is a simple class containing username and password.
I mostly agree about the delpoy/undeploy parameters.
4/ Implementation package should be separated from interface package.
definitely.
5/ We also need a way to create the war!
yeah (ugh :-P)
-Vincent
-- Christopher Lenz /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:cactus-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-dev-help@;jakarta.apache.org>
