>> Am I missing something? Yes, the problem is imo the name. What we might try is to have a long string where we concatenate all criterias together, and then do a md5 over it. That means there is a low chance of clashes but a high chance of the being able to re-create the same class name. Although once we hit the field of CDI Extension modifications it is not 100% anymore.
That was the reason why we bound the generated procy classes to their beans. What's wrong with this approach? Why don't you like that? LieGrue, strub > Am 01.03.2020 um 08:16 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Up, I'd like to get it - worse case with a spi - for next release to at > least enable to become native even if not yet trivial. > > 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> > > > Le lun. 11 nov. 2019 à 20:40, Romain Manni-Bucau <rmannibu...@gmail.com> a > écrit : > >> @Mark: so it means my proposal work, right? ;). Joke apart my proposal was >> not to have 1 proxy per type but 1 stable name per proxy without changing >> the number of classes and reuse the existing one if it already exists in >> the classloader. >> The only part which can fail is this last one since you can start twice a >> container in the same classloader and change the meta so the proxy but >> since the proxy contains the intercepted method markers in its name the >> reuse is safe. >> >> So I think it is ok even if the naming convention can likely be refined a >> lot, no? Am I missing something? >> >> 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> >> >> >> Le lun. 11 nov. 2019 à 20:28, Mark Struberg <strub...@yahoo.de.invalid> a >> écrit : >> >>> 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 >>>>>> >>>>> >>>>> >>> >>>
