On Sun, Jan 20, 2019 at 5:33 PM Sam Hague <[email protected]> wrote: > On Fri, Jan 18, 2019 at 5:49 PM Robert Varga <[email protected]> wrote: > >> On 18/01/2019 23:35, Sam Hague wrote: >> > >> > >> > On Fri, Jan 18, 2019 at 5:24 PM Tom Pantelis <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > >> > >> > On Fri, Jan 18, 2019 at 4:13 PM Sam Hague <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Any idea if there is a portable java method that can take json >> > as input and output java objects? Or some example code that >> > maybe isn't as generic, but with some case-specific coding could >> > do the same? >> > >> > The use case is for writing unit tests. Every new listener I add >> > tests for I always create helper methods to fill out the java >> > objects, write to mdsal, do some verifications, write some more >> > and so on. It would be much more readable to simply input a json >> > into this new helper method and out pop a java object that can >> > be written to mdsal. >> > >> > I imagine the restconf project has something similar since it >> > parses incoming json. Or maybe it is using some libraries to do >> > the same? >> >> [...] >> >> > Nice, Ok this looks like a good way to do it. I could extract that piece >> > of code and feed it the models I know need to be converted. And that >> > should be pretty lightweight for that piece of code, right? Doesn't look >> > like there are many dependencies just for that part. >> >> Assuming you get through the black magic of setting up >> BindingRuntimeContext and SchemaContext -- but you can get all of that >> from AbstractDataBrokerTest. >> > When you say get from the Abstract, do you mean if I add that in it will > be there - or do you mean it is already there and I just need to expose it? >
Sam, I am wondering if the org.opendaylight.controller.blueprint.ext.DataStoreAppConfigDefaultXMLReader could be of any interest / value to you in this context? I'm also using this in https://github.com/vorburger/opendaylight-simple/blob/d6ca32ba5d4031cab6abb520606f642fdcac60d8/src/main/java/org/opendaylight/controller/simple/ConfigReader.java (which I'll "upstream" some day); the purpose there is configuration files not test data, but I think it may be re-usable by you for what you're after. >> Can you file an improvement to extend AbstractDataBrokerTest with that >> sort of capability, please? >> >> I know JSON is the rage these days, but genius went a different route, >> using a combination of normal builders and Xtend. The result looks very >> reasonable: >> > Yes, NetVirt started this with Michael and moved to Genius with his lead. > >> >> >> https://github.com/opendaylight/genius/blob/master/itm/itm-impl/src/test/java/org/opendaylight/genius/itm/tests/xtend/ExpectedDeviceVtepsObjects.xtend >> >> For bonus points: >> >> 1) it is part of compilation, hence you get rather immediate feedback >> when you mess up, rather than dealing with parsing exceptions >> > How is this much different than creating helper builders? Unless it is > easier. But the goal with json is because we always use json to test via > the restconf and it is readable, so that had great value in the tests. You > were already going to make the json, so reuse that to feed the test and > then you focus on the test. I admit I didn't see the xtend that much easier > than builders. > > It also seems xtend related stuff keeps breaking or requiring parent bumps > to fix, which makes it difficult to rely on the tests. > >> >> 2) you can reuse them just as you would with normal constants >> >> 3) cross-reference navigation works (with an eclipse plugin) >> > Intellij... > just FYI there used to be an Xtend plug-in for IntelliJ, see https://plugins.jetbrains.com/plugin/8073-xtend-support and https://plugins.jetbrains.com/plugin/11412-xtend-support-fork- but AFAIK no longer maintained. But IMHO just editing those "data" Xtend files in a text editor, and having the compiler (mvn) check that they are vaild, is still nice I think. We could also look at using Kotlin instead of Xtend some day (I'm unlikely to personally have time for it in the near future though). > Regards, >> Robert >> >> _______________________________________________ > Discuss mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/discuss >
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
