WarParser.parseWebContext() insufficient

• Key: CACTUS-84
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Vincent Massol
• Reporter: Brian Topping
• Component/s: Other
• Fix Version/s: 1.6

Environment

Operating System: Windows XP
Platform: All

Description

Hi, thanks for a great tool!

WarParser.parseWebContext() is not sufficient for the needs of all
deployments. We are using the jboss3x container configuration with a jboss-
web.xml file defining the context root at "/". But this makes the application
untestable, since the only option for WarParser.parseWebContext() is to use
the root name of the war file for the context name to be looked up.

Because of the age of the application, it is impractical to change the the app
under testing to a context other than root. Even so, doing so would violate
the tenet of not changing the app for testing.

Given that multiple containers can exist with different methods of determining
the web context, the loop over containers in CactusTask.execute should clone
deployableFile, then give the container a shot at renaming the context. This
seems to be the most sane way of changing things. Alternately, a
configuration element for the ant target could be created, but that seems less
desirable without built-in intelligence at the container level.

Comments

[Brian Topping]

Created an attachment (id=9779)
Fix for bug. Sorry about useless diffs, checkstyle was pissing me off and I let IDEA handle the formatting of the file

[Vincent Massol]

Hi Brian,

I'm currently applying your patch. Could you explain to me the need for making
the DeployableFile cloneable?

Thanks
-Vincent

Yes, the inclination on making it cloneable was such that a standalone
DeployableFile could be sent to each container more easily. This is desirable
since each container may have an app configured for a different context, port,
or whatnot. By cloning the DeployableFile before allowing it to be modified,
each container can modify it at will.

This is not the most desirable architecture, but because of the number of
changes and the need to keep the patch size manageable, I chose this. I know
from personal experience that patches that are too large tend to not get
applied. If I had my way about it (and I remember what I was doing in there
correctly. it was a few weeks back now), I would change the contract such that
the container client called setter methods on the container sequentially and
let the container override those if it found better values in the container
configuration. This may have some detail missing, like I said, it's been a
while. The cloneable seemed the best way to keep the meddling to a minimum.

hope that helps...

[Vincent Massol]

I've committed your patch to CVS. I had to apply it manually as the patch
wasn't recognized by Eclipse. Strange.

Thanks for the patch!
-Vincent