Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <1c5e5908-ca90-9753-e03b-4b95e17216cf@oliver-heger.de>
References: <f5629ee6-8ad1-eca2-e281-bbe6cfaa9b9b@pobox.com>
 <d2e97bb0-c0be-b66c-c0a1-c7a64c47e485@oliver-heger.de> <f17815b6-5dfb-49a9-48d8-e5a7983514a0@pobox.com>
 <915346ba-ce6e-866b-c9ad-67b82785a672@oliver-heger.de> <0e1b158f-f97b-e2b1-8d48-672e6409c7e4@pobox.com>
 <CAJW_9fdyC0hHpRN4sE2eiusTSGC+kKKnuRGN6LwWaQWATjtjAA@mail.gmail.com> <1c5e5908-ca90-9753-e03b-4b95e17216cf@oliver-heger.de>
From: Aaron Gadberry <aaron@gadberry.com>
Date: Mon, 14 Nov 2016 15:51:17 -0600
Message-ID: <CAJW_9fdR0R=0APs01jqjKDw3riSvf62t5M5EMaZx3Xnnbri1pQ@mail.gmail.com>
Subject: Re: [configuration] Combined Configuration examples
To: Commons Users List <user@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a114701062802f0054149d88e
archived-at: Mon, 14 Nov 2016 21:51:46 -0000

--001a114701062802f0054149d88e
Content-Type: text/plain; charset=UTF-8

Thanks Oliver!

On Mon, Nov 14, 2016 at 3:24 PM, Oliver Heger <oliver.heger@oliver-heger.de>
wrote:

> Hi Aaron,
>
> Am 14.11.2016 um 18:38 schrieb Aaron Gadberry:
> > Hi All,
> >
> > A follow up question.  Is there a way to view the combined XML?  I am
> > constantly missing elements not knowing if it is my paths or my original
> > files or the combiner.
>
> what you could do is to copy the combined configuration into a
> XMLConfiguration and save this to a file. XMLConfiguration has a
> constructor that accepts a hierarchical configuration; so you pass in
> the combined configuration. Then the configuration can be saved to file
> or dumped to an output stream:
>
> XMLConfiguration copy = new XMLConfiguration(combined);
> FileHandler handler = new FileHandler(copy);
> handler.save(new File("target.xml"));
>
> Oliver
>
> >
> > Thanks,
> >
> >
> >
> > On Sun, Nov 13, 2016 at 2:54 PM, Greg Torrance <greg.torrance@pobox.com>
> > wrote:
> >
> >> Thanks Oliver.
> >>
> >> I think I understand what you're saying about why Channel 4 would not be
> >> included with the OverrideCombiner (if it doesn't exist in
> testfile1.xml).
> >> I am sorry to hear, though, that attributes are not used at all for
> >> matching with OverrideCombiner. If I'm understanding it correctly, that
> >> means it can't really be used for overriding just specific list items,
> as
> >> the entire list would have to be represented, in the same order, in both
> >> primary and overriding files, or the wrong list item might be
> overridden.
> >> (For example, if the primary list had Channels 1, 2, and 3, and the
> >> override list had only Channel 2, then it would attempt to override
> Channel
> >> 1 with the info from Channel 2.) Is my understanding correct?
> >>
> >> Anyway, I'm going to experiment a bit and try to make sure I have a good
> >> understanding of how this works.
> >>
> >> Thanks again for the help.
> >>
> >> Greg
> >>
> >>
> >> On 11/13/2016 01:51 PM, Oliver Heger wrote:
> >>
> >>> Hi Greg,
> >>>
> >>> Am 13.11.2016 um 18:41 schrieb Greg Torrance:
> >>>
> >>>> Hi Oliver,
> >>>>
> >>>> Thanks for the reply. That is helpful!
> >>>>
> >>>> Hm, it looks as if the examples are partly incorrect. I assume that
> >>>>>
> >>>> the channel with id="4" should not be part of testfile1.xml, but only
> be
> >>>> contained in the second file. It should appear in the results of union
> >>>> and  merge combiner. Does that make sense?
> >>>>
> >>>> I'm not clear why -- if the channel with id="4" is not contained in
> >>>> testfile1.xml -- why it will not end up in the results from all three
> >>>> combiners. Why just union and merge and not override, too?
> >>>>
> >>> On a higher level, OverrideCombiner detects that both files have a list
> >>> of channels. Therefore, it copies the first list and ignores the second
> >>> one. So the channels element in the first file overrides the one in the
> >>> second file.
> >>>
> >>> As for the attributes, do I understand correctly that the attribute
> >>>> values for elements are used, essentially, as "key" values to
> >>>> distinguish the various elements for combining purposes? And if the
> >>>> values of any attributes of two elements differ, then the elements
> would
> >>>> be considered different elements for combining purposes? (Said another
> >>>> way, if two elements have a set of attributes in common, if the values
> >>>> for those common attributes are the same, the elements will be
> >>>> considered to match.) Does that make sense? Is that correct?
> >>>>
> >>> This is true only for MergeCombiner. The other combiners do not try to
> >>> match nodes in both configurations based on their attribute values;
> they
> >>> take two source nodes at the same position in the hierarchy and produce
> >>> a result node that has all the attributes of the two source nodes.
> >>>
> >>> Oliver
> >>>
> >>> Thanks again for the reply.
> >>>>
> >>>> Greg
> >>>>
> >>>> On 11/13/2016 12:05 PM, Oliver Heger wrote:
> >>>>
> >>>>> Hi Greg,
> >>>>>
> >>>>> Am 13.11.2016 um 15:07 schrieb Greg Torrance:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I am trying to work out the precise differences between
> >>>>>> OverrideCombiner, UnionCombiner, and MergeCombiner. However, the
> >>>>>> examples on this page
> >>>>>> (https://commons.apache.org/proper/commons-configuration/use
> >>>>>> rguide/howto_combinedconfiguration.html)
> >>>>>>
> >>>>>> are confusing to me.
> >>>>>>
> >>>>>> testfile1.xml and testfile2.xml both contain Channels with id="4",
> >>>>>> however none of the Combiner Results shows any Channels with id="4".
> >>>>>> And the Notes on the right-hand side of the page contain no mention
> of
> >>>>>> Channel 4.
> >>>>>>
> >>>>>> Am I missing something? Are the examples correct?
> >>>>>>
> >>>>> Hm, it looks as if the examples are partly incorrect. I assume that
> the
> >>>>> channel with id="4" should not be part of testfile1.xml, but only be
> >>>>> contained in the second file. It should appear in the results of
> union
> >>>>> and merge combiner. Does that make sense?
> >>>>>
> >>>>> What I'm really trying to understand is the impact of attributes in
> the
> >>>>>> way the various combiners choose to combine elements. (Any pointers
> to
> >>>>>> further documentation on this would be appreciated.)
> >>>>>>
> >>>>> Some more information can be found in the Javadocs of the combiner
> >>>>> classes:
> >>>>> - UnionCombiner states: "Another limitation is the handling of
> >>>>> attributes: Attributes can only have a single value. So if two nodes
> are
> >>>>> to be combined which both have an attribute with the same name, it is
> >>>>> not possible to construct a proper union attribute. In this case, the
> >>>>> attribute value from the first node is used."
> >>>>>
> >>>>> - OverrideCombiner has an addAttributes() method with the following
> >>>>> documentation: "Handles the attributes during a combination process.
> >>>>> First all attributes of the first node are added to the result. Then
> all
> >>>>> attributes of the second node, which are not contained in the first
> >>>>> node, are also added."
> >>>>>
> >>>>> - The merging behavior of MergeCombiner is also described in its
> class
> >>>>> documentation.
> >>>>>
> >>>>> Does this help?
> >>>>> Oliver
> >>>>>
> >>>>> Thoughts?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Greg
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------
> ---------
> >>>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: user-help@commons.apache.org
> >>>>>>
> >>>>>> ------------------------------------------------------------
> ---------
> >>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: user-help@commons.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: user-help@commons.apache.org
> >>>>
> >>>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: user-help@commons.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: user-help@commons.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

--001a114701062802f0054149d88e--