https://bz.apache.org/bugzilla/show_bug.cgi?id=58143
Bryn <brynco...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Resolution|WONTFIX |---
Status|RESOLVED |REOPENED
Priority|P2 |P3
--- Comment #6 from Bryn <brynco...@gmail.com> ---
As suggested by Mark I have reopened this as an enhancement.
I have also come across this issue. In short registering a transformer in a
ServletContextInitializer was too late for classes that are scanned as part of
the @HandlesTypes mechanism, they are already loaded and are therefore not
transformed.
It would be great if we could have an alternative mechanism to register
transformers before scanning takes place.
Ideally this would be automatic registration rather than requiring the
developer to configure anything, thus allowing them to include the library with
the transformer in and benefit without referring to installation instructions.
This was my original goal of registering the transformer in a
ServletContextInitializer.
With this in mind the ServiceLoader mechanism or something similar could be
considered.
Library developers would create a resource containing the fully qualified class
names of their transformers at:
META-INF/services/java.lang.instrument.ClassFileTransformer
Transformers would be enumerated and registered before scanning takes place.
Even if JDK ServiceLoader implementation is not used, perhaps due to
performance, then the mechanism is at least well understood by developers.
Instead of having custom config specific to Tomcat the docs can just say that
ClassFileTransformers are discovered via ServiceLoader. This raises the chances
that other servlet containers would adopt the same approach.
I note that Jetty have an addTransformer method on their classloader as well,
but using ServiceLoader would be container independent.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
