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 >> >>> >> >> >> >> >> >>
