13:45:49 <devinavery> #startmeeting jquery_xpath_for_md_sal_intern
13:45:49 <odl_meetbot> Meeting started Thu Aug 21 13:45:49 2014 UTC.  The chair is devinavery. Information about MeetBot at http://ci.openstack.org/meetbot.html.
13:45:49 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:45:49 <odl_meetbot> The meeting name has been set to 'jquery_xpath_for_md_sal_intern'
13:46:12 <devinavery> #chair regXboi
13:46:12 <odl_meetbot> Current chairs: devinavery regXboi
13:46:41 <devinavery> #info Neel is debugging the list problem. He has identified some odd behavior with the way we handle unkeyedlists
13:47:11 <devinavery> So, in talking with Neel this morning I think I might have an idea where the problem is
13:47:46 <Neel_B> devinavery: post the xml here
13:48:06 <Neel_B> also is that how it is or how it is in md-sal supposed to be ?
13:48:37 <devinavery> The way the normalized nodes are nested together is a little funny in terms of the unkeyedlist.
13:48:58 <devinavery> Basically there is one object (the unkeyedlist) which wraps the list of values.
13:49:09 <devinavery> Yet when we see the output XML we strip away that outer wrapper
13:49:35 <devinavery> So, if we were to just translate the nodes exactly as they are, without stripping anything away, we would likely have XML that look like this: http://pastebin.com/8P8ktE6G
13:49:52 <devinavery> Notice the "unkeyedlist" tag that I added which wraps all of the childtoasterlist tags
13:50:09 <Neel_B> okay so thats how it is and we have to handle it
13:50:15 <Neel_B> properly
13:50:30 <devinavery> However, restconf produces XML WITHOUT the wrapping unkeyedlist tag (and we said we want to mirror restconf so people can know how to write xpath statements).
13:50:33 <Neel_B> okay simlilrly leafset node too then ?
13:50:45 <devinavery> Neel_B: lets hold off on leaf set for a second
13:50:48 <devinavery> I haven't thought about that one yet
13:50:55 <Neel_B> okay
13:51:15 <devinavery> So, what we need to do is strip away the unkeyedlist outer tag - basically throwing that node away
13:51:40 <Neel_B> okay
13:51:44 <Neel_B> so
13:51:49 <devinavery> But right now we DONT do that. We create a node which represents the unkeyedlist, and then we try to correct it when we start iterating into the children
13:51:53 <Neel_B> unkeyedlist has child 1  2 3
13:52:29 <Neel_B> okay devinavery continue
13:52:38 <devinavery> I think what we want to do is when we are calculating the firstChild or nextSibling, if that firstChild or next sibling is an unkeyedlist, then we should immediately strip it away and not even create a NodeBuilderElement for it
13:53:31 * devinavery is getting together some examples... one minute
13:56:07 <devinavery> Ok. Just pasted some modified psudo code here: http://pastebin.com/HG0auxtX
13:56:58 <devinavery> The idea is right now we blindly get the next NormalizedNode and pass it into an element. I think we need to inspect what the next node is, and if it is an unkeyedlist, then we need to pull its children up make them siblings, effectively throwing away the unkeyedlist node
13:59:47 <devinavery> Neel_B: does this make sense?
14:00:03 <Neel_B> looking to the code
14:03:33 <Neel_B> oky we are also checking for child
14:03:57 <Neel_B> if its unkeyedlist or not
14:04:58 <Neel_B> so we don't have to check whether the node is unkeylist or not
14:06:37 <devinavery> I think I follow. we no longer need the unkeyedlist instance of check which operates on the node field in the NodeBuilderElement (because that will never happen)
14:06:47 <devinavery> Instead we need to check for it BEFORE we create a NodeBuilderElement
14:07:03 <devinavery> and if found, then handle it correctly
14:11:17 <Neel_B> okay
14:11:26 <Neel_B> trying out the codefew minutes
14:12:10 <devinavery> #info devinavery suggest that we need to handle the unkeyedlist instance of check BEFORE we create a NodeBuilderElement, not afterwards. See text for full details. Neel_B trying out
14:16:54 <Neel_B> seems like it works but i am runnging tests
14:19:11 <devinavery> ok
14:24:10 <regXboi> I've caught up now with the thread
14:24:16 <regXboi> and it all makes sense to me
14:26:41 <Neel_B> ive seen a null pointer error
14:26:48 <Neel_B> rechecking if i did it right
14:33:21 <Neel_B> my implementation was wrong
14:33:27 <Neel_B> retrying the tests
14:36:53 <Neel_B> devinavery: http://pastebin.com/QAwNYVxp
14:37:12 * devinavery looking
14:37:13 <Neel_B> regXboi: please look at the out put
14:37:42 <devinavery> definitely something funny about that output./ :)
14:38:58 <regXboi> it looks like we've knitted the siblings together in a way that isn't so good
14:39:08 <Neel_B> i got
14:41:31 <Neel_B> the issure
14:41:35 <Neel_B> let me correct it
14:45:22 <Neel_B> when we are adding the iterators
14:45:38 <Neel_B> won't the parent change
14:46:12 <devinavery> I am not sure I follow your question...
14:46:20 <regXboi> ditto devinavery's comment
14:48:04 <Neel_B> i am bit ocnfused with recursion here
14:48:12 <Neel_B> so let me get clear and ask you
14:48:14 <Neel_B> at once
14:55:06 <Neel_B> devinavery:
14:55:09 <Neel_B> regXboi:
14:55:12 <Neel_B> you here
14:55:35 <regXboi> yes
14:56:02 <devinavery> Yup
14:58:53 <Neel_B> can you helpme assign the child here
14:59:06 <Neel_B> what happens it
14:59:13 <Neel_B> first node is toaster
14:59:28 <Neel_B> then the first child of toaster is the unkeyedlistnode
14:59:59 <Neel_B> so we take it iterate it and then assign its child
15:00:10 <regXboi> so the point is
15:00:12 <Neel_B> as the child of toaster
15:00:25 <regXboi> yes
15:00:44 <Neel_B> but the sibling thing
15:00:45 <regXboi> actually, I would say we iterate it and assign EACH child as a child of toaster
15:02:33 <Neel_B> i am finding it hard to do that
15:02:35 <Neel_B> code-wise
15:02:39 <devinavery> The first child of toaster is an unkeyedlistnode. So you get ITs children, and take the first value and make that the first child. Next you would take the children from the unkeyedlistnode and the remaining child iterator and merge them together
15:02:49 <devinavery> Can you share what code you have so far?
15:02:56 <Neel_B> okay
15:03:00 <Neel_B> i will update the git
15:03:11 <Neel_B> devinavery: that's what i have don
15:03:21 <Neel_B> but we are missing something in that
15:03:30 <Neel_B> i got it but am not able to tell
15:04:37 <devinavery> Ok. When you get git update I will take a look. Perhaps I am thinking about this wrong
15:05:07 <Neel_B> done
15:05:13 <Neel_B> and let me tell you
15:05:50 <Neel_B> we are thinking of unkeyedlistnode in a wrong way
15:06:01 <Neel_B> but am not sure what part is wrong
15:11:02 * devinavery is reviewing code
15:15:02 <regXboi> the problem is in getSibling I think
15:15:06 <regXboi> and or getParent
15:16:09 <Neel_B> get parent is passed as an arguement
15:16:14 <Neel_B> can't be wrog
15:16:17 <Neel_B> i guess
15:17:48 <devinavery> I think getSibling needs this logic too of checking for an unkeyedlist
15:18:10 <regXboi> actually
15:18:12 <regXboi> hang on
15:18:20 <regXboi> what is line 155 doing?
15:19:16 <devinavery> That whole block should actually go away
15:19:32 <devinavery> Lets walk through the logic here...
15:19:33 <Neel_B> sorry i forgot to comment but i did test with out them
15:19:54 <regXboi> I followed the logic up to 155
15:20:09 <regXboi> and I think if 155 is commented out, we should be closer to where we want to be
15:20:30 <Neel_B> regxboi
15:21:07 <Neel_B> commment out that whole else if block
15:21:13 <Neel_B> and try running
15:21:30 <devinavery> The problem is that getSibling needs the same logic (I think)
15:21:35 <regXboi> well
15:21:51 <regXboi> are we modifying an iterator we are iterating over?
15:22:08 <regXboi> I should say while we are interating over it?
15:22:23 <devinavery> Walking through the code: we start with the root toaster node. Toaster - getNextSibling returns null. Toaster.getFIrstChild should return toasterManufacture.
15:22:49 <devinavery> regXboi: we may have too - not sure
15:22:57 <Neel_B> toaster.getfirstchild
15:23:04 <Neel_B> returns the unkeyedlist
15:23:10 <regXboi> devinavery - that's a *VERY* dangerous thing
15:24:02 <regXboi> and yes, getSibling needs the same logic
15:24:23 <devinavery> regXboi: I'll illustrate my thinking - I think we are fairly safe
15:24:24 <regXboi> because we have to stitch from the end of the unkeyedlist to the
15:24:59 <Neel_B> okay
15:25:10 <regXboi> oh wai
15:25:11 <Neel_B> devinavery: tell us
15:25:13 <regXboi> er wait
15:25:22 <regXboi> no never mind
15:25:49 * devinavery is working on a code walk through - one moment
15:28:26 <devinavery> See http://pastebin.com/b5KXi9bL
15:29:23 <devinavery> So I took the XML that we were getting before and just did a walk through
15:29:25 <regXboi> did you change code to get there?
15:29:48 <devinavery> That is the output we were getting before we tried to do anything fancy with unkeyedlists
15:30:16 <regXboi> so, why were we trying to get fancy with unkeyedlists?
15:31:03 <devinavery> Because restconf strips away the unkeyedlist wrapper and places its children at a higher level
15:31:04 <devinavery> for some reason
15:31:46 <devinavery> Looks like we lost Neel
15:32:03 <Neel_B> regXboi devinavery did i miss anything
15:32:23 <devinavery> See http://pastebin.com/b5KXi9bL
15:32:29 <devinavery> So I took the XML that we were getting before and just did a walk through
15:33:15 <regXboi> note: tomorrow is the deadline - we may have to leave unkeyedlists as a todo
15:33:48 <regXboi> In fact I'd say back out to what we had before we messed with unkeyedlists, add docs and commit and call it success
15:34:09 <devinavery> Agree. We should probably put that on hold for now and work on getting something submitted to ODL
15:35:15 <Neel_B> oaky about that
15:36:04 <Neel_B> directory struture
15:36:14 <Neel_B> what part of the goes to where
15:36:25 <devinavery> #info having some trouble at the moment with recursion in regards to the unkeyedlists. WE are going to table that work to get some code checked into ODL for tomorrow (intern deadline)
15:37:48 <devinavery> Neel_B in the e-mail prior I suggest two bundles - one for the tests, and one for the implementation. At this point I think we can make due with a single bundle and we can split it up later.
15:38:06 <regXboi> yes... I would call the bundle sal-xpath
15:38:42 <regXboi> the patch needs to modify sal-parent to add it as a module
15:39:25 <regXboi> and I'd call the packages org.opendaylight.controller.md.sal.xpath and org...md.sal.xpath-it
15:39:58 <regXboi> yes, I'm cutting corners, but so be it
15:39:59 <Neel_B> okay
15:40:49 <Neel_B> okay i will create a folder in md-sal
15:40:52 <Neel_B> right ?
15:40:53 <regXboi> yes
15:41:09 <devinavery> regXboi: given the rough nature of this, we could even skip adding this code to the sal-parent pom.xml file
15:41:10 <Neel_B> with sal-xpath name and add ?
15:41:34 <regXboi> devinavery: let's add it but comment it out with explanation
15:41:43 <regXboi> so that people can enable it if they want
15:41:50 <devinavery> regXboi: ok.
15:42:08 <regXboi> Neel_B: once you have sal-xpath directory
15:42:30 <regXboi> then you need to put the pom.xml in there
15:42:44 <regXboi> and the code goes under src/main/java/<package path>
15:43:22 * devinavery stepping away for a minute.
15:43:31 <devinavery> regXboi - you are a chair as well on the meetbot
15:43:36 <regXboi> I'd put the Test java file under src/test/java/<package path>
15:43:38 <Neel_B> what code
15:43:49 <regXboi> the other java files under src/main/java/<package  path>
15:43:53 <Neel_B> okay
15:43:58 <Neel_B> package is
15:44:00 <regXboi> and then the yang files we've played with as src/test/resources
15:44:10 <regXboi> packages org.opendaylight.controller.md.sal.xpath
15:44:30 <regXboi> for all modules
15:44:36 <regXboi> er java files (test included)
15:45:21 <regXboi> so... ToasterTest.java goes under src/test
15:45:25 <Neel_B> okay
15:45:33 <Neel_B> what to write in pom ?
15:45:38 <Neel_B> pom.xml*
15:46:43 <regXboi> for the first patch set, just copy the toaster-it pom.xml you were using
15:46:45 <regXboi> *but*
15:47:24 <regXboi> change the parent groupId to org.opendaylight.controller
15:47:32 <regXboi> and artifactId to sal-parent
15:47:55 <regXboi> and your artifactId to sal-xpath
15:48:02 <regXboi> and set packaging to bundle
15:48:35 <regXboi> and let's see what happens when we try to build it within the controller
15:48:41 <regXboi> *before* we propose the comment
15:49:34 <Neel_B> packaging ?
15:50:04 <regXboi> yes...
15:50:14 <regXboi> <packaging>bundle</packaging>
15:50:22 <regXboi> <name>sal-xpath</name>
15:50:36 <Neel_B> nothing like that in this
15:50:41 <regXboi> <description>Xpath access</description>
15:50:46 <regXboi> I know ... you need to add them
15:51:00 <regXboi> right after the parent closes and you set the artifactId
15:51:14 <regXboi> look at one of the pom for sal-dom-xsql to see what I mean
15:51:36 <devinavery> regxboi / Neel_B - I need to run. regXboi: can you end the meeting?
15:51:48 <regXboi> let's get some actions
15:51:56 <regXboi> because I need to go to a meeting in <10 myself
15:52:01 <regXboi> so we need to close this up
15:52:05 <devinavery> ok
15:52:14 <Neel_B> okay okay
15:53:01 <devinavery> Ok. I will write some actions here
15:53:46 <devinavery> #action: Neel_B to take his code and check it into ODL as a single bundle for now
15:53:47 <Neel_B> okay
15:54:06 <devinavery> #action Neel_B will try and get his bundle compiling within the open daylight controller
15:54:36 <devinavery> #action Neel_B will propose a patch on the controller - be sure to put [DO NOT MERGE] at the beginning of your commit message
15:55:04 <devinavery> #info - refer to text for specifics from regXboi on how to implement etc.
15:55:22 <devinavery> regXboi / Neel_B - anything else?
15:55:41 <regXboi> that's good for now
15:55:59 <devinavery> Alright. Thanks all.
15:56:05 <Neel_B> okay i will try that
15:56:06 <devinavery> #endmeeting