the include command causes an error

[dvhwgumby]

Hi folks,

If I try to parse a .conf file with an include directive I get the error Error: reader() should not be called on resources

I am calling hocon::program_options::parse_file(filename, reasoner_options, true);

I'm running on MacOS.

Also I'm not sure how to specify the search directories for "include" though at the moment we have a single flat directory so this doesn't matter.

[MikaelSmith]

That's strange, what does your include directive look like?

I think there are some pretty strict limitations on it right now, but I've definitely used it for something like include file("/absolute/path") and include classpath("local/file").

Actually, I take that back... not sure I've used those examples with this hocon parser.

[luben]

I think you are hitting #94

[luben]

BTW, as I see some people commenting, is this project maintained? I sent a PR for fixing another bug with included files (#95) without any reaction for more than 3 months. @dvhwgumby , sorry for the noise,

[dvhwgumby]

Hmm. The lightbend parser says it wants ```include “foo”``` — and it can be used inside an object (though that’s way more sophisticated than we need)! I tried your suggested syntax and our java code (using the lightbend parser) rejected it. We verified this in the head of the GitHub config repo So, support for ```include “foo”``` would help a lot. As far as directories: I’m perfectly happy to change directories in my code to manage them. That is painless now I know it’s the mechanism. Thanks for building this package btw — it has already saved my bacon. Took me less than a day to integrate (using factor and pxp as examples as well as the source) — and most of that time was figuring out the include issue.

…

Sent from my iPhone

On Jan 16, 2018, at 13:35, Michael Smith ***@***.***> wrote: That's strange, what does your include directive look like? I think there are some pretty strict limitations on it right now, but I've definitely used it for something like include file("/absolute/path"). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dvhwgumby]

FWIW, the "spec" for HOCON ([https://github.com/lightbend/config/blob/master/HOCON.md#includes]) considers the syntax our team used to be legit.

[MikaelSmith]

Understood. This is currently an incomplete implementation of the spec. It would be nice to improve it, but I'm not personally spending a ton of time on it.

I'm surprised the lightbend parser rejected include file("foo"), since they seem to claim to support it in https://github.com/lightbend/config#features-of-hocon.

[SeaTalk]

I ran into a similar situation.
In my case, I have a.conf and b.conf both in directory "ProjectDir/conf/".
a.conf is like

{ include "b.conf" ...}

when I run code in directory "ProjectDir/bin/", I always get an error:
Something went wrong when parsing hocon file. Exception message:reader() should not be called on resources

I wonder how I can fix that.

[MikaelSmith]

I can give some suggestions of where to look to start a fix. Our code mirrors the lightbend/config implementation fairly closely, so you can use that to compare where we might be missing some implementation.

The parser is in src/config_document_parser.cc. parse_context::parse_include is the first place I'd look, which at least accepts include "foo". It's possible we're setting that up with the wrong type, but I suspect the actual problem is later. It's possible parse_context::parse_include in src/config_parser.cc is a problem.

If b.conf is empty, do you get an error? Possible the parser for the included file is not setup correctly.

[SeaTalk]

In my case, I fix it by changing some code. And my change exists here . For now, it works fine for me. I want you guys review my code and find out where bugs may lay.
Thanks a lot ~

[MikaelSmith]

Thanks for providing that! Not sure when someone might get to looking at it. If anyone's interested in turning that into a PR, I can try to help review it.

[MikaelSmith]

I believe this is fixed by #115. Please re-open the issue if I'm mistaken.