RE: Remote Cactus

[Vincent Massol <vm...@pivolis.com>]

Hi Thomas,

Sorry for the extremely long delay. It's a pity I wasn't more responsive as
you really seem to understand Cactus well and that's not common! :-). Anyway
see below my answers/comments.

> -----Original Message-----
> From: Th. Schapitz [mailto:shalmaneser@ePost.de]
> Sent: lundi 6 décembre 2004 12:06
> To: Cactus Developers List
> Subject: Re: Remote Cactus

[snip]

> >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).
> >
> >
> >
> Er, well actually I didn't! This is, because I'm actually deploying in a
> separate task outside of
> 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)

You're right of course. The problem is that having to do J2EE deployment for
testing is something that was too complex to setup for most Cactus users
(it's already hard to write some tests). Thus we've worked towards providing
some tools to provide a turnkey solution. I think this helped users to adopt
Cactus. Now, we recognize that this is not the goal of Cactus and this is
reason we have now started the Cargo project (http://cargo.codehaus.org).
The plan is to migrate Cactus to use it.

> 
> >>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).

I've just applied your patch for CACTUS-81. Thanks a lot and sorry for the
delay!

[snip]

> >>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 think it's fine for now. I think we should focus on migrating to Cargo
first as this will probably change a lot our Ant integration.

> >>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.

I'm not sure what problem you've had. Was is a problem when running Ant?

> 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.

:-) This is because we had started to migrate to Maven for our build but
we've not finished and this is a work in progress. I'm not even sure the
Maven build still works as it's not been touched for a while.

> 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. 

Yes, that's the reason. It's because Gump works by controlling the
classpaths used by Ant (using the ignore* property you mention). This is
because it builds all others project from their repository and its goal is
to ensure all projects work with latest built versions. Thus in the code
snippet above, Gump will ignore the commons.logging.jar, xerces.jar and
xlmapis.jar jars.

> 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.

Strange that it broke your build. Which version of Ant are you using? Which
OS are you running on? When you say it breaks your build, are you talking
about the Ant build or building using Gump?

> 
> Similarily, you need this to be present in the classpath of  the javac
> task within
> documentatition/build.xml.

Strange again as it works fine here. I would be curious to find the reason
for these 2 differences we have...

[snip]

Thanks a lot. Having some test to prove that it works would be cool but I
cannot think of an easy way to perform an integration test... Let me know if
you have an idea.

Cheers,
-Vincent



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org