Sure!
Think about having an interface and 3 producer methods. Each with different
proxy configuration. Means 3 different bytecode optimisations for the same
class.
Or having an interface in an EAR and 4 WARs which have their own impls. Still
the proxy gets generated and loaded via the shared EarClassLoader for class
visibility reasons.
So there are scenarios where you end up with n proxies - each with different
bytecode - for the same class.
LieGrue,
strub
> Am 11.11.2019 um 20:16 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> @Mark: not sure what you mean and which case you have in mind. Can you
> precise your answer please and what prevents my patch to work?
>
> Le lun. 11 nov. 2019 à 20:13, Mark Struberg <strub...@yahoo.de.invalid> a
> écrit :
>
>> no we still need it imo
>>
>>> Am 09.11.2019 um 16:30 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
>>> :
>>>
>>> Hi everyone,
>>>
>>> I wonder if we can drop the loop
>>> in org.apache.webbeans.proxy.AbstractProxyFactory#getUnusedProxyClassName
>>> to ensure we have stable names for proxies.
>>> The rational behind that is to:
>>>
>>> 1. Stop creating the same class again and again when we
>>> start/stop/restart/restop/... a container in the same classloader
>>> 2. Ensure we have deterministic names for the same proxy (currently, when
>>> the name are conflicting, it depends what was executed before, even in
>> the
>>> same app!).
>>>
>>> From a quick review we only need to mark the intercepted methods in the
>>> proxy name to ensure we can reuse the existing class. Therefore a quick
>>> proposal for the proxy name suffix is:
>>>
>>> + protected String getProxySuffix(final Method[] interceptedMethods,
>>> + final Method[]
>> nonInterceptedMethods) {
>>> + return "__i_" + getMethodsId(interceptedMethods);
>>> + }
>>> +
>>> + private String getMethodsId(final Method[] methods, final
>>> Predicate<Method> filter) {
>>> + return Stream.of(methods)
>>> + .filter(filter)
>>> + .map(m -> m.getName() +
>>> +
>>>
>> Stream.of(m.getParameterTypes()).map(Class::getSimpleName).collect(joining()))
>>> + .collect(joining("_"));
>>> + }
>>>
>>> Full patch is available here:
>>> https://gist.github.com/rmannibucau/6f6cdf8d605387ac8820dcbc76e67909
>>>
>>> Wdyt?
>>>
>>> If not desired, should I
>>> enrich org.apache.webbeans.spi.DefiningClassService with that feature?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>
>>
>>
