Oki, will try to push a service this week. Side note: I agree on JPMS point but there is no link to jigsaw, it is linked to the enforced security more than modules.
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 mer. 12 juin 2019 à 07:59, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > +1 if it is switchable to the old mechanism. > > When loading the proxy class in a different classloader you cannot access > any protected or package scoped methods as it is basically treated as > 'outside'. A package - even if it has the same package name - is only > treated the same if it is loaded by the very same ClassLoader. Different > CL, different package so to say. > > Plus: Jigsaw doesn't deliver. The adoption rate is sub-stelar. If not to > say crappy. And for a reason. It doesn't add much benefit from a security > pot. Especially when compared to the costs. Reminds me a bit to > SecurityManager. Sounds nice in theory, but is a performance hog and not > easy to get safe. So almost nobody is using it. I guess the same will > happen to Jigsaw. > > LieGrue, > Strub > > > > Am 11.06.2019 um 12:37 schrieb Thomas Andraschko < > andraschko.tho...@gmail.com>: > > > > hmmm > > basically +1 if we can solve the protected/package scoping by a fallback > > > > lets wait about mark's opinion? > > > > Am Di., 11. Juni 2019 um 11:23 Uhr schrieb Romain Manni-Bucau < > > rmannibu...@gmail.com>: > > > >> Hi guys, > >> > >> Do we want to add an option to switch to a classloader based proxy > >> definition? > >> > >> Idea is that instead of using reflection or unsafe to define our > proxies we > >> create a class loader - likely in WebBeansContext and shared accross all > >> AbstractProxyFactories. It looks like (ignore the visibility, I took it > >> from a poc as a nested class): > >> > >> private static class InternalClassLoader extends ClassLoader { > >> private final ConcurrentMap<String, Class<?>> classes = new > >> ConcurrentHashMap<>(); > >> > >> private InternalClassLoader(final ClassLoader > applicationClassLoader) { > >> super(applicationClassLoader); > >> } > >> > >> > >> @Override > >> protected Class<?> loadClass(final String name, final boolean > >> resolve) throws ClassNotFoundException { > >> final Class<?> clazz = classes.get(name); > >> if (clazz == null) { > >> return getParent().loadClass(name); > >> } > >> return clazz; > >> } > >> > >> private Class<?> getOrRegister(final String proxyClassName, final > >> byte[] proxyBytes) { > >> return classes.computeIfAbsent( > >> proxyClassName.replace('/', '.'), > >> n -> { > >> final Class<?> defined = > >> super.defineClass(proxyClassName, proxyBytes, 0, proxyBytes.length); > >> resolveClass(defined); > >> return defined; > >> }); > >> } > >> } > >> > >> > >> Then AbstractProxyFactory would make getProxyClass behaving as - > assuming > >> we have proxies the instance of this classloader: > >> > >> return proxies;. > >> > >> I suspect it can need to use that classloader instead of TCCL for > >> deserialization but it is not a big deal too. > >> > >> The big advantage is to work on java >= 9 without warning (WARNING: > Illegal > >> reflective access ) but it has a disavantage to not support > >> protected/package scope proxying (since we use 2 classloaders). > >> > >> If we want to be clever we could use both strategies at the same time, > i.e. > >> if we can proxy through this classloader then we do, otherwise we keep > >> current impl. > >> > >> Any opinion? i'd really like to have a clean run on java 11 for 2.0.12 > or > >> 2.0.13, even if we must add a few limitations like this visibility > thing. > >> > >> wdyt? > >> 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 > >>> > >> > >
