I noticed that in ContinuationClassLoader you aren't actually using the
marker interface to decide what to instrument any more. Is this by
design? I also noticed a similar comment in the TODO file.
If so, I can remove the Continuable interface.
I still see some value in retaining the ContinuationCapable interface,
as this seems to be something we can use for detecting errors at
runtime. But since ContinuationCapable doesn't need to be visible to
users, I wonder if we can move it to the bytecode subpackage.
Another thing about ContinuationClassLoader. Right now this class is
hard-coded to recognize the javaflow test packages, but this needs to be
parameterized. Also, in JUnit, the list of "excluded packages" can be
read from a data file [1]. I suggest we implement something like that. I
don't think it makes sense for this file to be a property file, so I
think we can just read this as an UTF-8 encoded text file where each
line specifies a new mask. Let me know how you think about me making
those changes.
BTW, I found this JUnit implementation interesting. It doesn't seem to
exclude any of the java.* or org.w3c.*, but it must be clearly working.
I never used the ClassLoader.findLoadedClass method before, but does
this method load all the classes in the bootstrap classloader?
Personally, I find the current ContinuationClassLoader bit too
error-prone. Because the parent ClassLoader can always load the same
class that a child ContinuationClassLoader can load, you can easily get
two Class objects that have the same name if you are not careful. This
happens, for example, if class X (which is outside the
'includeInRewriting' list) refers to class Y (which is inside the
'includeInRewriting' list.) When you later tries to load Y through the
ContinuationClassLoader, you get another copy Y'.
In my day job, I saw several JAXB users who face this kind of issues
while using JAXB in JUnit, and these issues are very hard to diagnose.
For this reason, I wonder if we can have another ClassLoader that works
more like a traditional URLClassLoader --- you tell it a set of
locations to look at, then the class loader loads a class file from it
with byte-code instrumentation. This requires a developer to have
separate location for a host and the code that runs inside the
continuation environment, but it eliminates a danger of having two
copies of the same class.
This class loader is useful for things like agent container or workflow
engines. URLClassLoader isn't reusable for us, but I think we can start
from AntClassLoader.
[1]
http://cvs.sourceforge.net/viewcvs.py/junit/junit/junit/runner/TestCaseClassLoader.java?rev=1.6&view=auto
--
Kohsuke Kawaguchi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
