Hi Thomas, > -----Original Message----- > From: Th. Schapitz [mailto:[EMAIL PROTECTED] > Sent: dimanche 5 d�cembre 2004 13:31 > To: [EMAIL PROTECTED] > Subject: Remote Cactus > > Dear Cactus developers, > > Because I stumbled on the same requirement, > I devised a fix to the issues Cactus-81 and Cactus-134, including the > option to test > using HTTPs, (provided you got the JSSE setup right, which I actually > didn't test). > > Are you interested?
Definitely! That's great. I'm curious how you solved the issue of remote WAR/EAR deployments for all supported containers (this is was the "hard" issue that I planned to fix in Cargo land by supporting remote deployments). > > If yes, I'd would apreciate some guidance, as to how to forward the fix > into the repository. > (The ant developers provide a patch mechanism for their project, but I > found no hint > to soemthing similar for jakarta-cactus) We are working similarly. See http://jakarta.apache.org/cactus/participating/index.html. Basically you simply have to attach patch against the corresponding JIRA issue(s). > > Anyway, before doing so, I'd like to discuss some things, that I might > fix too, while > beeing at it. Sure > > 1.) > What I actually did, was adding property accessors 'Server' and > 'Protocol' to the Interface > Container, and matching attributes and setters to AbstractContainer as > well as ContainerWrapper. > Accessors and Mutators are declared final. > I then modified CactusTask, to get the values from there. cool > > IMHO, this is appropriate, because for any use case I can see, all web > containers are accessible > via IP interface. > However, checking this against the other existing Container Attribute > 'Port', this introduces > some incoherence, because this Attribute has > - its accessor declared in Container, > - no attributes and Mutators in AbstractContainer > - instead, you find finalized mutators and accessors in all but one > derivations (AbstractCatalinaContainer) > > Options are now: > - living with that inconsistency. > - cleaning up, by moving the accessor and mutator to AbstractContainer. > Optionally, we could finalize them there too, but this would break > backward > compatibility, if somebody else derived from there, declaring this > methods. > - Introducing an additional class having this, and inserting it into > the inheritance > tree after AbstractContainer. (What could be an apropriate name?) > > I would can live with all the options, and volunteer to to implement, > which ever > the committers might agree upon. I've not fully understood but do what you think is right. > > 2.) I suggest, I'm also fixing the message to show the URL of the > server, that is > used for the test, as well as giving a feedback after each > Testinvocation in > Verbose Mode. Looks good > > 3.) When using the ant scripts supplied on my XP installation, I had > some problems > with the classpath, that seems to rely on GUMP for including the > ant.jar. I'm not familiar > with neither GUMP nor Maven, so fixed it, by simply changing the build > files for integration/ant > and documentation. Not sure what problem you had. You also mention Gump and Maven but the tool we're using to build Cactus is Ant. > > 4.) I'm going to fix the documentation for the additional attributes > too, as soon as I > figured out how. (A pointer to the correct location would be welcomed) All our doc is written in xdocs format (all files are in jakarta-cactus/documentation/docs/xdocs). > > 5.) Just to mention, I did all the programming and checks against files > I checked > out via anoncvs from HEAD two days ago? this ok? it is! Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
