You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using Interception API with Guice, the enhanced classes by Guice follow a specific pattern which is controlled/generated by Enhancer or AbstractGlueGenerator. The naming pattern includes the hashCode(). The design choice is understandable.
However, there're use cases where the Class.getName() is distorted by the naming pattern. For example, consider a continuous profiling that runs on an application. In every instance of JVM, the class names are generated with a different hashCode(). Maybe there's a way to always ensure a consistent hashCode() but that also depends on the JVM.
In this use case, since the name of the classes are different per JVM instance, the collected profiling data appear as if they're collected from different object types; though the underlying object is all the same.
For example, if MyService is intercepted, then it appears in the profiling data as both MyService$$EnhancedByGuice$$111 and MyService$$EnhancedByGuice$$222. They are both the same type but intercepted in different JVM instances or the same JVM at different times.
⚠️ The above names would cause distorted data in a context where the class name is key -- e.g. continuous profiling based on JVM class names.
I am looking for a way to extend/configure/plug a way into how Guice generates the proxyName -- link
protectedAbstractGlueGenerator(Class<?> hostClass, Stringmarker) {
this.hostClass = hostClass;
this.hostName = Type.getInternalName(hostClass);
this.proxyName = proxyName(hostName, marker, hashCode());
}
/** Generates a unique name based on the original class name and marker. */privatestaticStringproxyName(StringhostName, Stringmarker, inthash) {
longid = ((hash & 0x000FFFFF) | (COUNTER.getAndIncrement() << 20));
StringproxyName = hostName + marker + Long.toHexString(id);
if (proxyName.startsWith("java/") && !ClassDefining.hasPackageAccess()) {
proxyName = '$' + proxyName; // can't define java.* glue in same package
}
returnproxyName;
}
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
When using Interception API with Guice, the enhanced classes by Guice follow a specific pattern which is controlled/generated by
Enhancer
orAbstractGlueGenerator
. The naming pattern includes thehashCode()
. The design choice is understandable.However, there're use cases where the
Class.getName()
is distorted by the naming pattern. For example, consider a continuous profiling that runs on an application. In every instance of JVM, the class names are generated with a differenthashCode()
. Maybe there's a way to always ensure a consistenthashCode()
but that also depends on the JVM.In this use case, since the name of the classes are different per JVM instance, the collected profiling data appear as if they're collected from different object types; though the underlying object is all the same.
For example, if
MyService
is intercepted, then it appears in the profiling data as bothMyService$$EnhancedByGuice$$111
andMyService$$EnhancedByGuice$$222
. They are both the same type but intercepted in different JVM instances or the same JVM at different times.I am looking for a way to extend/configure/plug a way into how Guice generates the
proxyName
-- linkThanks
Beta Was this translation helpful? Give feedback.
All reactions