Hi,
I have noticed that package protected constructors can not be used,
and I tracked it down to the FragmentClassloader that doesn't create a
matching constructor for non-(public || protected) constructors.
Once I changed that to non-private, I get this remarkable exception;
Caused by: java.lang.IllegalAccessError: tried to access method
org.qi4j.library.scheduler.SchedulerService$ThreadFactory.<init>(Lorg/qi4j/library/scheduler/SchedulerService;)V
from class org.qi4j.library.scheduler.SchedulerService_ThreadFactory_Stub
which says that the package protection is trying to be compromised,
even though it seems to be the same package.
So to be sure, I added printing the package of the class and the superclass;
Class package: package org.qi4j.library.scheduler
Superclass package: package org.qi4j.library.scheduler
and they are identical!!!
SO, I suspected that this was classloader related;
Class CL: org.qi4j.runtime.composite.FragmentClassLoader@47ad6b4b
Superclass CL: sun.misc.Launcher$AppClassLoader@1ef6a746
Sure enough...
I assume (guys like Stuart would know for sure) that there are some
kind of validation of cross-classloader packages in the JVM.
So, I am placing an open question; Are we doing too much, or too
little, classloading tricks in Qi4j today?
Should we require that the FragmentClassloader becomes the System
Classloader for the entire Qi4j application, i.e. all client code
would be loaded via it? Or should we simply leave it as it is and live
with the rough edges around class/method protection?
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
