1

I,m using XMLunit for comparing XMLs.i have xmls as below.

<e>
 <accounts>
  <number>56482</number>
  <name>ererr</name>
 </accounts>
</e>    
<indicator>
 <e>
  <name>name1</name>
  <value>value1<value>
 </e>
 <e>
  <name>name2</name>
  <value>value2<value>
 </e>
</indicators>

as in above xml, I need to write different element selector conditions for different e i.e I need to write a separate element selector condition for //e and different element selector condition for //indicator/e. right now im using below code

ElementSelectors.conditionalBuilder()
.whenElementIsNamed("e").thenUse(ElementSelectors.byXPath("//indicator/e/name",ElementSelectors.byNameAndText))
                .elseUse(ElementSelectors.byName)
                .build();

but this condition best suited for //indicator/e. I need to have a separate condition like 

 ElementSelectors.conditionalBuilder()
    .whenElementIsNamed("e").thenUse(ElementSelectors.byXPath("//e/number",ElementSelectors.byNameAndText))
                    .elseUse(ElementSelectors.byName)
                    .build();

I'm struck here and please suggest me on overcoming this issue.

Mohamed Rafiudeen
  • 147
  • 1
  • 2
  • 7

1 Answers1

0

The conditional builder offers a more generic when which accepts a Predicate<? super Element> so you can code up more specific conditions like

when(e => "e".equals(e.getNodeName())
    && "indicator".equals(e.getParentNode().getNodeName()))

of course you better add some null-checks and error handling, but you get the idea.

Stefan Bodewig
  • 3,260
  • 15
  • 22
  • thank you @Stefan, I have 2 xmls of 10mb each, when I use custom element selectors, its taking more than an hour to produce result.. when I just use default selectors it gives quick response, is there anyway I can improve the performance? – Mohamed Rafiudeen May 04 '18 at 09:47
  • Oh, this is huge. The default selector is doing the same thing as the first `equals` check in my example (actually it is doing something more complex, taking namespaced nodes into account), so I'm a bit surprised. I wouldn't expect `getParentNode` to take that much time. Maybe you've got a chance with splitting the comparison into two independent comparisons using `NodeFilter` to get rid of one kind of `e`s in each of them? – Stefan Bodewig May 05 '18 at 13:21