davsclaus opened a new pull request, #26709:
URL: https://github.com/apache/camel/pull/26709
## Summary
Follow-up to #26678 (review point 1). A `.groovy` file with
`@BindToRegistry` worked with `camel run` but not after `camel export`: only
`camel-kamelet-main` registered `CompilePostProcessor`s, so in a camel-main,
Spring Boot or Quarkus project the file was compiled and the annotated class
then silently dropped, and the custom simple function failed with `Unknown
function` on the first message.
The fix keeps camel-main untouched and puts the default behaviour where the
compilation happens:
- **camel-support**: the three Camel-annotation post-processors that were
private inner classes of `AnnotationDependencyInjection` in camel-kamelet-main
are now public classes in `org.apache.camel.support.compile`:
`BindToRegistryCompilePostProcessor` (with the `lazyBean` constructor),
`TypeConverterCompilePostProcessor`, `EventNotifierCompilePostProcessor`. Code
moved verbatim.
- **camel-groovy**: `DefaultGroovyScriptCompiler.postCompile` uses the
processors in the registry when there are any (camel-jbang's, which also handle
the Spring and Quarkus annotations and `lazyBean`), and otherwise the three
built-in ones. So a `@BindToRegistry` / `@Configuration` class is bound in
Camel's registry, a `@Converter` class registered as type converters, and an
`EventNotifier` added, in every runtime that runs the Groovy compiler — gated
as before by `camel-groovy` on the classpath and a source matching
`camel.main.groovyScriptPattern`. Plain classes and scripts are still not
instantiated.
- **camel-kamelet-main**: `AnnotationDependencyInjection` registers the
camel-support classes instead of its own copies; the Spring/Quarkus processors
and injectors are unchanged.
Reach: Spring Boot and Quarkus go through the same compiler, so a Groovy
`@BindToRegistry` class in an exported project of either runtime is now a
Camel-registry bean (available to `bean:`, `ref:`, simple functions, `#bean:`
placeholders); it is not a Spring/CDI bean, same as beans from
`PackageScanHelper` or YAML `- beans:`. The Spring/Quarkus annotations on a
Groovy class stay CLI-only. No new configuration option, no API change.
## Tests
- `GroovyDefaultCompilePostProcessorTest` (camel-groovy): a plain context
with **no** `CompilePostProcessor` in the registry; a `@BindToRegistry` Groovy
class is usable as `${maskEmail(${body})}`, and a `@Converter` Groovy class as
`convertBodyTo(Order.class)`.
- Existing `GroovyCompilePostProcessorTest` (registry processor takes
precedence) and camel-kamelet-main `AnnotationDependencyInjectionTest` pass;
camel-groovy 108 tests, camel-kamelet-main 42 tests green.
## Docs
- simple-advanced and camel-jbang-beans: the "works only in the CLI" notes
from #26678 replaced with the every-runtime behaviour and the
Camel-registry-not-container boundary.
- groovy-language: post-processor paragraph updated.
- 4.23 upgrade guide: camel-groovy entry updated; notes the new public
classes in camel-support.
Depends on #26678 (branched from it; will be rebased onto `main` once that
is merged, so the diff here shows both until then).
_Claude Code on behalf of davsclaus_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
