Config Error Handling

Config Error Handling

Two failure phases, two reporting paths

Membrane config errors surface differently depending on when they're thrown, and that's the first thing to get right.

Setter-time — inside an @MCAttribute/@MCChildElement setter, during YAML property binding (annot/.../yaml/parsing/binding/PropertyBinder.java, populate()). That catch (Throwable cause) re-wraps into new ConfigurationParsingException(cause.getMessage()) and attaches a ParsingContext (source location), so RouterCLI renders a highlighted > YAML snippet pointing at the offending line. Mind the message: reflection wraps a setter's own exception in InvocationTargetException, and PropertyBinder does not unwrap it, so the message it copies is the wrapper's (null) — the real text sits in cause.getCause().getMessage(). The @MCElement(collapsed=true) scalar path in ObjectBinder does unwrap (e.getTargetException()). Example: WsuTimestampInterceptor.setTtl (core/.../soap/wsse/WsuTimestampInterceptor.java) catches DateTimeParseException from Duration.parse and rethrows a ConfigurationException with a concrete valid-example ("PT5M").

Init-time — inside interceptor.init(Router), reached via DefaultRouter.init() → AbstractRouter.initProxies() → proxy.init(this), i.e. after all YAML parsing has finished. The YAML bootstrap does carry a ParsingContext into the bean registry, but nothing on this initProxies() path passes it on, so an interceptor's init() has no source location to report — not fixable per-interceptor without a cross-cutting change to plumb it through Router/interceptor init. ConfigurationException thrown here is caught by SpringConfigurationErrorHandler.handleConfigurationException (core/.../exceptions/SpringConfigurationErrorHandler.java:128), which prints a plain "************** Configuration Error ***..." / "Reason: <cause message>" block — no YAML snippet. This is the existing, accepted behavior for every interceptor's init()-time checks (missing keystore, bad key alias, unsupported algorithm, ...), not a bug to chase per class.

Prefer failing at init()-time (config-load time) over lazily at first-request time — see DigitalSignatureInterceptor.validateConfiguration() for the pattern (checked in init(), before any request is handled).

Writing a good ConfigurationException message

• Name the bad attribute and the value that was given.
• List valid options built from real constants, not hand-typed strings, so the list can't drift from what's actually supported — e.g. DigitalSignatureInterceptor.SUPPORTED_DIGEST_ALGORITHMS is built from javax.xml.crypto.dsig.DigestMethod.*, verified experimentally against the JDK's DOM XMLSignatureFactory rather than assumed from the constant list.
• Wrap the causing checked exception with new ConfigurationException(message, cause) rather than swallowing it — cause.getMessage() is still visible via Reason: in the init-time path.

Testing pattern

• Init-time checks: follow DigitalSignatureInterceptorTest's initWith(references...) + assertThrows(RuntimeException.class, () -> initWith(...)) idiom — set the invalid state on a fresh interceptor with an otherwise-valid config, assert init throws.
• Setter-time message propagation: annot/src/test/java/.../YAMLParsingErrorTest.java builds ad-hoc @MCElement classes and asserts on the rendered error report (see attribute()) — use that as the template. There is currently no test covering a setter-thrown exception's message, which is why the InvocationTargetException gap above goes unnoticed; add one there if you touch that path.