Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#417 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
42/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Ruhig
Tech-Stack
java
Bereich
backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Java
Sterne
227
Forks
81
Ø Merge
3 T. 6 Std.
Gemergte PRs (30 T.)
15

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus OpenIntegrationEngine/engine

Alle Issues in OpenIntegrationEngine/engine

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.