commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kohsuke Kawaguchi>
Subject [javaflow] class loader
Date Tue, 02 Aug 2005 04:50:07 GMT

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.

Kohsuke Kawaguchi

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message