Ok for the JPMS point - java.lang.reflect.AccessibleObject#logIfOpenedForIllegalAccess, can mean we need to document the --add-opens too?
About OSGi, I think it should work but also not sure it should be used since the OSGi classloaders have another specific API which abstracts the classloader itself. 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 à 10:24, Mark Struberg <[email protected]> a écrit : > 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 <[email protected] > >: > > > > 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 <[email protected]> > 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 < > >> [email protected]>: > >>> > >>> 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 < > >>> [email protected]>: > >>> > >>>> 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 > >>>>> > >>>> > >> > >> > >
