> -----Original Message----- > From: Christopher Lenz [mailto:cmlenz@;gmx.de] > Sent: 24 October 2002 20:37 > To: Cactus Developers List > Subject: Re: [Cactus Plugin] Comments on IContainerProvider mechanism and > co > > 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. > > > > 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 > > 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.
+1 > > 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. > +1 > 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. +1 to all. > > > 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) > Cool. Thanks Chris for this nice summary and explanations! Let's start rolling now ! :-) -Vincent > > -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>
