Skip to content

Conversation

@gansheer
Copy link
Contributor

@gansheer gansheer commented Oct 22, 2025

Closes #5478

Improve test coverage for transformer features:

  • Custom transformer (.withJava())
  • DataFormat transformer (.withDataFormat())
  • Endpoint transformer (.withUri())
  • @DataTypeTransformer annotation (unnamed and named)

Add support in native mode with discovery of subclasses of org.apache.camel.spi.Transformer .

Note: I am not sure if I should move the registration code for reflection in CamelNativeImageProcessor or use something like @BuildStep(onlyIf = NativeOrNativeSourcesBuild.class). Not sure what the best practice is in this case so I kept it in Camel Processor, don't hesitate to comment review on this.

@gansheer gansheer force-pushed the feat/5478-transformer branch from b8e717d to 7d65a0a Compare October 22, 2025 15:40
@gansheer gansheer marked this pull request as draft October 22, 2025 19:13
// Register transformer classes for reflection so they can be instantiated at runtime
transformerClasses.forEach(className -> reflectiveClass.produce(
ReflectiveClassBuildItem.builder(className)
.methods()
Copy link
Contributor

@jamesnetherton jamesnetherton Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick - if Camel does not need reflective access to any methods on the transformer classes, then you can remove .methods(). It may be enough to only enable constructor reflection (enabled by default with ReflectiveClassBuildItem).

BuildProducer<ReflectiveClassBuildItem> reflectiveClass) {

IndexView view = combinedIndex.getIndex();
DotName dataTypeTransformer = DotName.createSimple("org.apache.camel.spi.DataTypeTransformer");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonder if instead of searching for @DataTypeTransformer, maybe we just find all subclasses of org.apache.camel.spi.Transformer? That way users would not need to tag any custom classes with @RegisterForReflection.


Set<String> transformerClasses = view.getAnnotations(dataTypeTransformer)
.stream()
.filter(ai -> ai.target().kind() == AnnotationTarget.Kind.CLASS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should also filter transformer classes that are part of the Camel core + components. They get loaded automatically from the META-INF/services files.

@gansheer gansheer force-pushed the feat/5478-transformer branch from 7d65a0a to f7fd82a Compare October 23, 2025 11:37
@jamesnetherton
Copy link
Contributor

jamesnetherton commented Oct 24, 2025

Overall it looks good to me.

use something like @buildstep(onlyIf = NativeOrNativeSourcesBuild.class)

I think we should in this case, since this change is specific to native support. There's no point in having the build step run for non-native.

@gansheer gansheer force-pushed the feat/5478-transformer branch from f7fd82a to bafec5d Compare October 24, 2025 07:21
@gansheer gansheer force-pushed the feat/5478-transformer branch from 5fcc0d2 to a9cd7d9 Compare October 24, 2025 07:54
@gansheer gansheer marked this pull request as ready for review October 24, 2025 07:54
@jamesnetherton jamesnetherton merged commit d8c22f6 into apache:main Oct 24, 2025
24 checks passed
@gansheer gansheer changed the title Add tests for transformer features and support @DataTypeTransformer in native mode Add tests for transformer features and support Transformer in native mode Oct 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support & test coverage for transformer features

2 participants