oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From holenoter <holeno...@me.com>
Subject Re: XMLValidation layer modifyElement
Date Fri, 27 May 2011 18:18:44 GMT
hey michael,

looks like a bug . . . you want to write the patch for this? . . . make an issue first in
JIRA (https://issues.apache.org/jira/browse/OODT) -- you can sign up for an account on the
site if you don't have one . . . my recommendation for a fix to this would be to change:

    private HashMap<String, List<Element>> productTypeElementMap = new HashMap<String,
List<Element>>();

to
    private HashMap<String, List<String>> productTypeElementMap = new HashMap<String,
List<String>>();

where the List<String> is a list of Element ids . . . then you will have to modify the
method getElements(ProductType) such that it first gets the list of Element ids from productTypeElementMap
and then creates a return List<Element> by getting the elements from the elementMap
. . . then a simple mod to XmlStructFactory.writeProductTypeMapXmLDocument such that it works
with the new map type (simple fix since all it uses is the Element ids anyway)

oh course, if you have a better idea feel free to explain it in the issue description when
you create it . . . and i'm sure´╗┐ other developers may have strong opinions on this fix.

-brian


On May 27, 2011, at 10:04 AM, "Starch, Michael D (388L)" <Michael.D.Starch@jpl.nasa.gov>
wrote:

> All,
>
> I looked at the XMLValidation layer's modifyElement function, and it doesn't appear to
modify elements that get put into the productTypeElementMap.
>
> Thus an element will be modified in the elements map (element id to element) but if it
is already mapped to a product type the product type to element map will maintain a reference
to the unmodified element. Is this intended behavior, or have I missed something?
>
> I had intended to use the modifyElement function, but with the purpose of updating any
occurrence of that element. If this is not the intended purpose I will find a workaround.
>
> -Michael Starch
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message