logging config in a svn working copy fails to load with elasticsearch 1.3

[thetuxkeeper]

elasticsearch 1.3 will try to import .svn/text-base/logging.yml.text-base as json and fail to set up logging as a whole.
I think it's not reproducible with subversion 1.7+ since a new .svn-format with hash-based filenames is used. But Debian wheezy/stable is still using subversion 1.6 and is what we use.
I found https://github.com/elasticsearch/elasticsearch/blob/1.3/src/main/java/org/elasticsearch/common/logging/log4j/LogConfigurator.java#L107 which is the problematic part.
imo it should at least skip "hidden" directories, if not be limited to some more strict rules (file extension whitelist without the "catch-all" default, ...).

I thought of only ignoring the failed file, but that could lead to strange errors too.
What if you have a logging.json. Then you would have a .svn/text-base/logging.json.text-base, which could import and override the original logging.json (local modified logging.json). => quite troublesome to find out why the changes don't work until you commit them :)

Known workarounds (also see https://groups.google.com/forum/#!topic/elasticsearch/8zlwEj12DjI):

1. Add "copy/move to logging.yml" command before startup (so that the file in .svn doesn't start with "logging.")
2. mount an empty directory over .svn (tmpfs, ...). Umount/mount if needed to work with svn <= that's the solution we use, since we mount it readonly over nfs and cp/mv doesn't work

I think both workarounds are quite dirty hacks and you shouldn't be forced to use those, just because you use a vcs.

[lifeforms]

We are seeing the same problem.

In our case, it turned out that logging.yml.sample is now being interpreted as a JSON file. (The .sample file is dropped by the FreeBSD package, as per convention)

This leads to the following startup error, which was initially tricky to diagnose... as logging didn't work :)

org.elasticsearch.common.settings.SettingsException: Failed to load settings from [file:/usr/local/etc/elasticsearch/logging.yml.sample] [...] Caused by: org.elasticsearch.common.jackson.core.JsonParseException: Unexpected character ('#' (code 35)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')

I feel that walking the tree and using all logging.* files will invite a lot of unexpected problems for others in the future too. For instance, think of someone editing the file and keeping the original in logging.yml.bak, which now also is parsed as JSON and causes the same startup failure.

[javanna]

This is being addressed in #7457. The plan would be to load only logging.*.yml, logging.*.yaml, logging.*.json and logging.*.properties, but keep throwing exception if the parsing of one of the files is problematic. How does that sound?
Closing in favour of #7457.