Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#417 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
227
Fork
81
Merge trung bình
3 ngày 6 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenIntegrationEngine/engine

Tất cả issue của OpenIntegrationEngine/engine

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.