ppkarwasz commented on issue #3875:
URL:
https://github.com/apache/logging-log4j2/issues/3875#issuecomment-3178128228
> What I plan to do on the implementation side is that this DI metadata will
be used to generate the GraalVM reachability metadata, and in the future, this
may also be useful for generating code for building plugins so we can avoid
reflection entirely. And while I haven't verified this yet, it might be simpler
to write code to transform one tree of classes into another tree of classes to
dump to JSON than it is to write two separate annotation processors.
What I’d suggest is tackling these problems incrementally:
* **Generate GraalVM reachability metadata directly** in the
`GraalVmProcessor`. There’s no strong need to introduce another layer of
indirection for this. Since generating the proposed injection metadata will
already require an annotation processor to process `@Inject` annotations, the
additional intermediate step seems avoidable.
* **Defer the broader enhancement** until we can evaluate it in the context
of existing tooling:
* Established, general-purpose dependency injection frameworks.
* Call graph generators. Dependency injection is a common challenge when
determining method reachability, not just for GraalVM. It may be best to wait
until @openrefactorymunawar’s Java call graph generator is released, then align
on a metadata format that could serve both GraalVM and the call graph generator.
Also, note that **Log4j already has a custom metadata format** for
documenting plugins ([Log4j
Docgen](https://logging.apache.org/log4j/tools/log4j-docgen.html#descriptor-generator)).
If needed, we could extend that format rather than inventing an entirely new
one.
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
