Remote Cactus

["Th. Schapitz" <sh...@ePost.de>]

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?

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)

Anyway, before doing so, I'd like to discuss some things, that I might 
fix too, while
beeing at it.

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.

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.

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.

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.

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)

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?

Regards,
Thomas

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

RE: Remote Cactus

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

Hi Thomas,

> -----Original Message-----
> From: Th. Schapitz [mailto:shalmaneser@ePost.de]
> Sent: dimanche 5 décembre 2004 13:31
> To: cactus-dev@jakarta.apache.org
> 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: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org