Rishi Verma created OODT-689:
--------------------------------

             Summary: XmlStructFactory generates invalid ProductType if policy 
is missing "<metadata/>" or "<metExtractors/>"
                 Key: OODT-689
                 URL: https://issues.apache.org/jira/browse/OODT-689
             Project: OODT
          Issue Type: Sub-task
          Components: file manager
    Affects Versions: 0.6
            Reporter: Rishi Verma
            Assignee: Rishi Verma
             Fix For: 0.7


The XmlStructFactory class [1] can generate invalid ProductType objects if an 
XML product-types.xml file has policy missing either the "<metadata/>" tag or 
the "<metExtractors/>" tag. Moreover, if these nodes are missing, the user is 
not informed about the missing elements and is instead presented with a 
NullPointerException when new policy is written automatically via the 
AddProductTypeCliAction (or other such tools).

I propose the following:
* XmlStructFactory's getProductType method should NOT default the 
initialization of the met (Metadata) object or the extractors 
(List<ExtractorSpec>) object to be null. Instead, they should be initialized as 
an empty Metadata object and an empty Vector<ExtractorSpec> list respectively.
* XmlStructFactory's getProductType method should warn the user via a Logger 
warning that either a "<metadata/>" or "<metExtractors/>" node is missing

The reason I propose we default the metadata and metExtractors object to be 
empty objects instead of null objects, is because of the way the ProductType 
[2] object constructor is configured. By default, instantiating a new 
ProductType object leads its internal Metadata and metExtractors objects being 
set to empty objects instead of null objects. However, through the 
XmlStructFactory, this pattern breaks when a metadata or metExtractors node is 
not present in policy - these objects are set to null and the new ProductType 
that is generated on line 202 of XmlStructFactory is corrupted. This can be 
prevented by a simple initialization change as proposed. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to