Vincent Massol wrote:
Er, well actually I didn't! This is, because I'm actually deploying in a separate task outside ofHi 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).
Cactus. In my perception, Cactus is primarily an JUnit extension, that focuses in testing within a
web container. It's not a tool, that should focus on how to cope with deployment on different
containers. In order to be able to access a remote container, it was just necessary to
be able to specify the containers base url.
(I agree, though, that some unified deployment mechanism for Web and J2EE-Containers
is something that is missing in ANT. But this is something in its own right, not only for cactus)
I just hoped, the committers would hint at their preference: tighter code, or backward compatibility.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.
Maybee compatibility isn't really an issue, because nobody else derives from there, but you'll never
know....
Well, looking through the directories and build files, I couldn't help but notice, that somebody added maven project descriptors (maven.xml, project.xml) to the source tree, for a purpose, I assume.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.
Than again, in integration/ant/build.xml you'll find the lines:
<path id="project.classpath">
<pathelement location="${commons.logging.jar}"/>
<pathelement location="${xerces.jar}"/>
<pathelement location="${xmlapis.jar}"/>
<!-- Required for Gump -->
<pathelement location="${java.class.path}"/>
</path>
The embedded comment clearly relates to a comment I saw somewhere
on apache, that Gump uses the ant classpath ignore feature, to get the
dependencies right. On my machine, this broke the build, because 'location' expects
a single directory or file, but ${java.class.path} contained a semicolon separated path.
The thing that has to be present there is the ant.jar.
Similarily, you need this to be present in the classpath of the javac task within
documentatition/build.xml.
Fixing this, makes the ant scripts work on my maschine, and shouldn't break GUMP
but I have the distinct feeling the the proper way should be, to declare the proper
dependency on ant, e .g. in the project descriptors? Unfortunately, this overstretchces
my current abilities.
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]
