Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#417 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
227
Forks
81
Merge medio
3 d 15 h
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenIntegrationEngine/engine

Todos los issues de OpenIntegrationEngine/engine

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.