[
https://issues.apache.org/jira/browse/OODT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ross Laidlaw updated OODT-741:
------------------------------
Description:
The TestXMLValidationLayer#testGetElements test currently fails when doing a
full build/test of the File Manager component, with the following result:
{panel}
Results :
Failed tests:
testGetElements(org.apache.oodt.cas.filemgr.validation.TestXMLValidationLayer):
There aren't exactly 4 elements in the test samples! expected:<4> but was:<11>
{panel}
This happens because the elementMap field in the XMLValidationLayer class is
static (i.e. a class variable), so any data assigned to it persists between
objects. When new data is written to the elementMap it is added or overwritten
depending on the value of the String key, but data isn't removed from it when
new XMLValidationLayer objects are created.
The way that the test is written would imply that each XMLValidationLayer
object should have its own elementMap. So I've experimented by removing the
'static' modifier from the elementMap, subToSuperMap and productTypeElementMap
fields. This causes all TestXMLValidationLayer tests to pass and does not seem
to affect any other File Manager tests (all other tests pass).
Would this be an acceptable change or will it prevent other things from working?
was:
The TestXMLValidationLayer#testGetElements test currently fails when doing a
full build/test of the File Manager component, with the following result:
{panel}
Results :
Failed tests:
testGetElements(org.apache.oodt.cas.filemgr.validation.TestXMLValidationLayer):
There aren't exactly 4 elements in the test samples! expected:<4> but was:<11>
{panel}
This happens because the elementMap field in the XMLValidationLayer class is
static (i.e. a class variable), so any data assigned to it persists between
objects. When new data is written to the elementMap it is added or overwritten
depending on the value of the String key, but data isn't removed from it when
new XMLValidationLayer objects are created.
I've experimented by removing the 'static' modifier from the elementMap,
subToSuperMap and productTypeElementMap fields. This causes all
TestXMLValidationLayer tests to pass and does not seem to affect any other File
Manager tests (all other tests pass).
Would this be an acceptable change or will it prevent other things from working?
> Should the elementMap, subToSuperMap and productTypeElementMap fields in
> XMLValidationLayer be non-static?
> ----------------------------------------------------------------------------------------------------------
>
> Key: OODT-741
> URL: https://issues.apache.org/jira/browse/OODT-741
> Project: OODT
> Issue Type: Bug
> Components: file manager
> Affects Versions: 0.7
> Reporter: Ross Laidlaw
> Assignee: Ross Laidlaw
> Labels: filemgr
> Fix For: 0.7
>
> Attachments: OODT-741.rlaidlaw.2014-08-06.patch.txt
>
>
> The TestXMLValidationLayer#testGetElements test currently fails when doing a
> full build/test of the File Manager component, with the following result:
> {panel}
> Results :
> Failed tests:
>
> testGetElements(org.apache.oodt.cas.filemgr.validation.TestXMLValidationLayer):
> There aren't exactly 4 elements in the test samples! expected:<4> but
> was:<11>
> {panel}
> This happens because the elementMap field in the XMLValidationLayer class is
> static (i.e. a class variable), so any data assigned to it persists between
> objects. When new data is written to the elementMap it is added or
> overwritten depending on the value of the String key, but data isn't removed
> from it when new XMLValidationLayer objects are created.
> The way that the test is written would imply that each XMLValidationLayer
> object should have its own elementMap. So I've experimented by removing the
> 'static' modifier from the elementMap, subToSuperMap and
> productTypeElementMap fields. This causes all TestXMLValidationLayer tests
> to pass and does not seem to affect any other File Manager tests (all other
> tests pass).
> Would this be an acceptable change or will it prevent other things from
> working?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
