the 'enforced' security is a side effect of the modules. It's a half baked OSGi. Btw, does your hack also work on OSGi? Have not looked at the commit yet due to time constraints :(
LieGrue, strub > Am 12.06.2019 um 08:11 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 >>>>> >>>> >> >>
