DanielLeens commented on PR #10799: URL: https://github.com/apache/seatunnel/pull/10799#issuecomment-4824395272
Thanks for calling this out. I rechecked the current staged head against that exact SPI boundary. You are right that `DebeziumAdapterFactory.getAdapter(...)` currently returns the first matching provider in `seatunnel-connectors-v2/connector-cdc/connector-cdc-base/src/main/java/org/apache/seatunnel/connectors/cdc/base/debezium/DebeziumAdapterFactory.java:46-63`, so the duplicate-match rule is implicit today. On the unchanged current head, though, I would still treat that as a future hardening point rather than a new blocker for this specific staged PR. The reason is that this revision still does not add production `DebeziumAdapter` registrations under `src/main/resources/META-INF/services/...`; the current staged scope is still the base contract/factory boundary, plus test-only coverage. So the ambiguous “two real providers match the same connector.class in one classloader” case is not user-reachable on this exact head yet. That said, I do agree with the direction of your suggestion. Once the first real connector-owned adapter registrations land, I would also prefer the contract to become explicit: - no match -> clear failure - exactly one match -> use it - more than one match -> fail fast and list the matches So I would keep the current staged foundation verdict as-is on this unchanged head, and I would treat the duplicate-match guard as a very reasonable next hardening step when the SPI starts carrying real production adapters. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
