Choosing a variable replacement delimiter

[eeverman]

Currently AndHow has one special configuration parameter that accepts the string java.io.tmpdir and replaces it (anywhere in the value and without delimiters) with the actual temp directory. Its a special case and a bit of a hack.

I'd like to improve this by adding some type of escape characters / delimiters to make it clear that the text is to be replaced during configuration loading, and extend the concept to any configuration string that wants to use it.

It could be really useful for lots of configuration values to be able to use auto-replacements for a short list of standard system properties, such as:

• java.io.tmpdir
• file.separator
• line.separator
• path.separator
• user.dir
• user.home
• user.name

But, its hard to choose a good escape / delimiter character sequence without colliding with other syntax that might require double escaping in some upstream system. Some possible ideas:

1. ${java.io.tmpdir} (used by lots of other systems, likely leading to collisions)
2. {{java.io.tmpdir}} (used by jinja)
3. [[java.io.tmpdir]]
4. . . .others

The trick is to pick some type of delimiters that are legal and don't have special meanings in any of the current or potential configuration sources, especially:

• command line args
• JNDI (often spec'ed in XML)
• environmental vars (on any platform)
• properties files
• Java's XML version of properties files (java will read properties files as text or XML)
• YML (not currently supported by AndHow, but often used to configure env vars)
• JSON (same caveat)
• Jinja (same caveat)

Ideally, someone could put a value in like this in a properties file:
MY_SPECIAL_DATABASE_FILE: [[user.home]][[path.separator]]db.export

What would be a good escape sequence delimiter for values?

[eeverman]

@alex-kar @duselmann - Do either of you have any ideas on this?

[duselmann]

If you are asking for a suggestion of which to use then I vote for JINJA.

[eeverman]

Actually, sort of the opposite of picking an existing one: What is a good special value scheme that is not an existing one?

If someone is encoding env vars via Ansible, they will be using JINJA, so I want to pick my own encoding that is distinct. I'm trying not to collide any existing tech, such as JINJA.