[ 
https://issues.apache.org/jira/browse/OODT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ross Laidlaw updated OODT-741:
------------------------------

    Attachment: OODT-741.rlaidlaw.2014-08-06.patch.txt

Here's a patch with the proposed changes.

> 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.
> 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)

Reply via email to