[wildfly-dev] WFCORE-648 Cascade Ear Exclusions Test Case

[Brian Stansberry]

Sure, that's fine. Just leave a comment about it in the PR description. 
For example, https://github.com/wildfly/wildfly/pull/7635

On 6/29/15 3:12 PM, Brandon Gaisford wrote:
>
> Hey all,
>
> I’ve completed the integration test case for WFCORE-648.  I’m just about to commit and create a PR against full.  Given that the core functionality doesn’t exist yet (outstanding PR in core) from the perspective of full, this integration test will fail the automatic tests kicked off by the CI.  I’m wondering if I should proceed with the PR?
>
> Brandon
>
> On Jun 23, 2015, at 7:45 AM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
>
>>
>> Thanks, I’ve created a PR for visibility.  I’ll keep working on the test cases.
>>
>> https://github.com/wildfly/wildfly-core/pull/834
>>
>> Brandon
>>
>> On Jun 22, 2015, at 9:12 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>>> I don't know enough about the details of this to have any suggestions
>>> re: how to validate that the exclusions are correct. But I don't think
>>> DeploymentAddHandlerTestCase is a good base to work from. It's a unit
>>> test of a particular class that uses mocks and doesn't involve
>>> DeploymentUnitProcessors at all. You probably need an integration test.
>>>
>>> On 6/22/15 1:35 PM, Brandon Gaisford wrote:
>>>> 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
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat