Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[BUG] Configuration Map keys containing dots silently fail to expand in connector fields (Velocity property navigation

Aberta
  • Algo errado?
#417 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
42/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Pouca atividade
Stack de tecnologia
java
Domínio
backend

Direção de pesquisa

Start at TemplateValueReplacer.getDefaultContext() and loadContextFromMap, which put the Configuration Map into the Velocity context as a flat map. Connector fields (e.g. Database Reader/Writer URL) are expanded with Velocity, so ${a.b.c} is property navigation, not a dotted key. Decide among docs, a UI warning on dotted keys, or a deploy-time log when ${...} is left unresolved; there is no linked PR and no comments yet.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

bug

Describe the bug
A Configuration Map key that contains dots — for example db.warehouse.url — is not
expanded when referenced as ${db.warehouse.url} in a connector field such as a Database
Reader/Writer URL, username or password. The raw ${...} text is passed through to the
connector, which then fails with an error that points at the connector rather than at the
key name.

Keys with no dots expand correctly in the same fields.

Consistently reproducible: yes, on every deploy, on both Database Reader and Database
Writer, in url, username and password.

The underlying cause is that connector fields are resolved with Velocity, where ${a.b.c}
means "object a, property b, property c" rather than a lookup of a flat key named
a.b.c. The Configuration Map is loaded into the Velocity context as a flat map
(TemplateValueReplacer.getDefaultContext() calls
loadContextFromMap(context, ConfigurationController.getInstance().getConfigurationMap())),
so a dotted key exists in the map but is unreachable through dotted reference syntax.
Velocity leaves an unresolvable reference untouched, which is why the literal is passed on.

I am not arguing Velocity should behave differently. The problem is that this fails with
no warning anywhere, and the resulting error misdirects.

To Reproduce

  1. Settings -> Configuration Map, add a key with dots:
    test.cfgmap.url = jdbc:postgresql://host.example.org:5432/db
  2. Create a channel with a Database Reader source.
  3. Set the Reader's URL to ${test.cfgmap.url}, driver org.postgresql.Driver,
    select statement SELECT 1.

Steps to reproduce the behavior:

  1. Deploy the channel.
  2. Look at the server log.
  3. See the deploy fail with the unexpanded literal.

Expected behavior
${test.cfgmap.url} resolves to the Configuration Map value, the same way a key without
dots does — or, failing that, some indication that the reference could not be resolved.

Actual behavior
The literal ${test.cfgmap.url} is handed to the connector:

Caused by: com.mirth.connect.donkey.server.ConnectorTaskException: Failed to initialize database connection
	at com.mirth.connect.connectors.jdbc.DatabaseReceiverQuery.initConnection(DatabaseReceiverQuery.java:124)
	at com.mirth.connect.connectors.jdbc.DatabaseReceiverQuery.start(DatabaseReceiverQuery.java:87)
	at com.mirth.connect.connectors.jdbc.DatabaseReceiver.onStart(DatabaseReceiver.java:115)
Caused by: java.sql.SQLException: No suitable driver found for ${test.cfgmap.url}
	at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:706)
	at com.mirth.connect.connectors.jdbc.DatabaseReceiverQuery.initSelectConnection(DatabaseReceiverQuery.java:340)

With a dot-free key (stedi_mode, whose value is P) the same channel produces:

java.sql.SQLException: No suitable driver found for P

which is the expected substitution — P is not a valid JDBC URL, so it fails, but the
value was clearly resolved.

With dot-free keys used for url, username and password throughout, the Database Reader
connects successfully, emits a row, and the Database Writer connects and sends
successfully. So both connectors do expand these fields; only the dots break it.

There is no WARN or ERROR anywhere saying a reference was left unresolved.

Screenshots
N/A — log output above.

Environment (please complete the following information):

  • OS: Windows Server 2025
  • Java Distribution/Version: OpenJDK 17.0.19 (bundled with the OIE installer)
  • Connect Version: Open Integration Engine 4.6.0
  • Database backend: PostgreSQL 17

Behaviour should be platform-independent — Velocity's grammar and Java .properties key
handling are the same everywhere.

Workaround(s)
Yes, and it is easy once you know: do not use dots in Configuration Map keys that will be
referenced from connector fields. Rename db.warehouse.url to db_warehouse_url and
${db_warehouse_url} resolves correctly.

Note that dotted keys still work fine from JavaScript, because
configurationMap.get('db.warehouse.url') is a literal string lookup rather than a Velocity
template. So the same key works in one place and silently fails in another, which is what
makes this easy to trip over.

Additional context
Dots are a natural convention for namespacing configuration keys and the Configuration Map
UI accepts them without complaint, so this is easy to walk into. I suspect it is the origin
of the fairly widespread belief that Configuration Map values "don't work in connector
URLs" — they do, as long as the key has no dots.

Possible resolutions, cheapest first:

  1. Documentation — note that keys referenced from connector fields must not contain
    dots, and that dotted keys remain usable from JavaScript via configurationMap.get().
    This alone would have saved me the investigation.
  2. UI warning when a key containing a dot is added to the Configuration Map.
  3. Log a warning at deploy time when a connector field still contains an unresolved
    ${...} after replacement.     This is the one I would find most valuable — it would
    surface the whole class of unresolved-reference mistakes (typos, deleted keys, wrong
    scope), not just dotted keys.

Happy to open a PR for the documentation change, or for option 3 if that is of interest.

Linguagem predominante
Java
Estrelas
227
Forks
81
Merge médio
3d 6h
PRs com merge (30d)
15

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de OpenIntegrationEngine/engine

Todas as issues de OpenIntegrationEngine/engine

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.