Thank you! I didn't know the Brooklyn yaml parser would accept json. I use various editors including Sublime which understands yaml and many other formats. My problem wasn't that the syntax was illegal yaml but that some items were assigned to the wrong collection and i was too much of a novice at Brooklyn to see that.
Sending sample yaml files back and forth by email damaged the indentation. This is why i prefer languages with explicit containment syntax. P On Thu, Mar 21, 2019, 2:26 AM Duncan Grant <[email protected]> wrote: > Peter, > > Just in case you hadn't realised JSON is allowed in almost all cases where > yaml is used. This is part of the yaml standard[1] and I think the main > thing you lose is the ability to use anchors[2]. > > Personally I'm a big fan of VIM and I find that as long as I keep file > sizes quite small then yaml indentation is perfectly manageable as VIM > shows indentation and will do simple auto-formatting. > > Regards > > Duncan > > [1] https://yaml.org/spec/1.2/spec.html#id2759572 > [2] > > https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json-when-to-prefer-one-over-the-other > > > On Sat, 16 Mar 2019 at 17:59, Peter Abramowitsch <[email protected]> > wrote: > > > Hi Geoff > > > > Ok, I think it's good now. I did use a brooklyn config substitution to > > create a rundir > > > > run.dir: $brooklyn:config("rundir") > > > > And then defined it in the app > > rundir: /Users/peterabramowitsch/manhattan/c2 > > > > And it nicely copied the artifacts I had defined with absolute paths - > such > > as jars and log4g config into the rundirs. And as you pointed out, each > > one got its own pid.txt so each process can be managed correctly. > > > > Many thanks for all your help and suggestions > > > > Turns out some of my problems were just incorrect indentation in the > Yaml. > > I am a developer with 38 years of experience, and I've been through and > > written my own tens of different formats for configuration, passing > through > > types where indentation mattered, like Make, Coffeescript, HAML (a rails > > formatter) hoping to never see them again. The problem with all of them > > is that one can create a mess where an item belongs to the incorrect > > collection / hash while visually it still looks perfect, and no syntax > tool > > will help you. It would be difficult to do that it in a format like JSON > > or XML. > > > > So here's my last suggestion. How about JSON as an alternative input > > format, or how about a kind of dump in Brooklyn which shows all of the > > entities and their properties it's *about* to create before it goes about > > creating them, throwing NPEs whose messages are hard to decipher. > > > > Peter > > > > > > > > On Thu, Mar 14, 2019 at 5:18 PM Geoff Macartney < > [email protected] > > > > > wrote: > > > > > Hi again Peter, > > > > > > As is often the way, looking at the email I just sent I suddenly > realised > > > what the problem with the pid file is - the catalog item is defining > the > > > run.dir as the home directory. Just leave out the definition of > run.dir > > in > > > the catalog item’s config. Then each entity gets its own run dir with > its > > > own pid.txt and you don’t need to do anything special to configure the > > run > > > dir per-entity. > > > > > > I knew something felt wrong! That’s what it was. > > > > > > Cheers > > > Geoff > > > > > >
