oscerd commented on PR #29746: URL: https://github.com/apache/camel/pull/29746#issuecomment-6848909352
Pushed `CAMEL-26847: Address review feedback - the native guard covers the expressions, failures name the option and the exception class, static entities are validated once, remote=false, no FQCNs, tests skipped on ppc64le/s390x` (1fa62b19e8a1) on top of cac577360f13. Points 2-8 of the review and the four logging threads: 2. **ppc64le/s390x**: the module sets `skipTests.ppc64le` and `skipTests.s390x`, as camel-langchain4j-embeddings does. Confirmed the cause in cedar-java 4.11.0: `EntityTypeName` calls `LibraryLoader.loadLibrary()` in its static initializer, so `CedarConfigurationTest` would have loaded the library through `CedarEntityUidExpression.init()`. 3. **init() under the guard**: `doStart` creates the engine first and then initializes the principal, action, resource and context expressions inside the same `LinkageError` guard, so a native failure raised by `EntityTypeName.parse` becomes the "unsupported platform" message; a configuration error of an expression still propagates as an `IllegalArgumentException`. `CedarConfigurationTest.nativeFailureWhileInitializingAnExpressionIsActionable` covers both, with a `Proxy` engine that needs no native library. 4. **Failure reports**: `reload()` tracks the step (reading, parsing, validating) and the option (`policiesResource`, `schemaResource`, `entitiesResource`), and the exception and the `WARN` line say `Cedar <step> of <option> failed (<reason>); no revision is active` on the first load or `; the previous revision is retained` afterwards. The reason is the exception class, or the evaluator's own finding when it rejected something itself: a failed schema validation lists the policy ids and the error kinds (`DetailedError.code`) from the `ValidationResponse`, a resource that is too large or has an unsupported scheme says so. SDK messages are neither logged nor retained as causes. The native message carries the exception class and the platform, and the engine version only when the SDK JAR declares one (point 8: no hardcoded `4.11.0`). `evaluate()` logs at `WARN` with the exception class, or with the evaluator's own reason for a rejected input (an expression that yielded no entity UID, a null or oversized context, invalid provider data); this is what the four gnodet-bot threads asked for, with the class instead of `e.getMessage()`. 5. `remote = false` on `@UriEndpoint`; the generated JSON and the catalog copy say `"remote": false`. 6. Without an `entityProvider` the request uses the snapshot's entities, which were validated at load, and `validateEntities` is not called per exchange; with a provider the merged set is validated as before. `CedarEvaluatorTest.staticEntitiesAreValidatedAtLoadNotPerExchange` counts the calls through a delegating `Proxy` engine. 7. Imports instead of FQCNs in `CedarEndpoint`, `CedarEvaluatorTest` and `CedarConfigurationTest`. Docs: the component page describes what a failed reload and an evaluation failure report and log, that the static entities are validated at load, and the startup message; catalog copies regenerated. Module build with tests green locally (Linux amd64). _Claude Code on behalf of oscerd_ -- 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]
