[wildfly-dev] WFCORE-648 Cascade Ear Exclusions Test Case
Brandon Gaisford
bgaisford at punagroup.com
Mon Jun 22 14:35:08 EDT 2015
Hey all,
I’ve completed my initial coding for this issue and spent 2-3 hours now trying to come up with a good test case. I’ve created a test ear that I was planning to include as a test resource to deploy during unit testing.
When I debug using the test ear during normal server startup, I’m seeing this operation and resource within the DeploymentDeployHandler:
operation
{
"operation" => "deploy",
"address" => [("deployment" => "test-ear.ear")]
}
resource
{
"persistent" => false,
"owner" => [
("subsystem" => "deployment-scanner"),
("scanner" => "default")
],
"runtime-name" => "test-ear.ear",
"content" => [{"hash" => bytes {
0x00, 0xbb, 0x8a, 0x3a, 0x61, 0x12, 0xa6, 0xec,
0x59, 0x69, 0xab, 0x9d, 0xda, 0xe1, 0x48, 0x0e,
0x68, 0x92, 0x9a, 0x03
}}],
"enabled" => undefined
}
I was thinking I could model my test case after the existing DeploymentAddHandlerTestCase (but instead target DeploymentDeployHandler) and then during the deployment phase inspect some internal state to verify the exclusions are correct in the ModuleStructureSpec. But now I’m questioning whether this is a bridge too far.
Does anyone have any bright ideas or advice on how I might move forward on this test case?
Thanks,
Brandon
More information about the wildfly-dev
mailing list