Class loading debugging

[starksm64]

I'd like to get a better view of what has visibility to a class from the system/domain level. What I would like is:

1. Be able to ask a policy, what policies have a resource/class
2. Be able to ask the BaseClassLoaderSystem what domains have a resource/class
3. What are the classpath elements that are visible starting from a ClassLoader. Sort of a URLClassLoader.toURLs() view.

[adrian.brock]

I'd like to get a better view of what has visibility to a class from the system/domain level. What I would like is:

1. Be able to ask a policy, what policies have a resource/class

You mean locally. That's two different questions depending on whether
it exports those resources/classes.
I also assume you mean a domain or the classloading system?

There's a different question as to whether it can see it from one of its imports
or the domain if it is importAll. But that's just the standard classloading api.

2. Be able to ask the BaseClassLoaderSystem what domains have a resource/class

That pretty much already exists, but it will only be exported classes and resources.
The only part that is missing is the ability to list the domains so you can iterate over
them and do loadClass/getResource.

3. What are the classpath elements that are visible starting from a ClassLoader. Sort of a URLClassLoader.toURLs() view.

There's no such thing in general. If the policy is a VFSClassLoaderPolicy
then you can ask what its VFS roots are and you could ask what other policies
it can see that are VFSClassLoaderPolicys or URLClassLoaders.
But the new classloading system has been designed to be flexible.
There's no direct dependency of URLs/VFS etc. Somebody can implement
a policy how they want.

[adrian.brock]

The one issue is that this is a management api.

So we need a way to identify the policy. Currently each policy has a "name"
but that's just for debugging purposes. In the deployment layer we
use the top level deployment name.

The domains do have a unique name.

Assuming the name is enough, I can see it being fairly trivial to implement
a management api like the following on the ClassLoaderSystem:

Assume similar api for getResources()

// Basic lists
Collection<ClassLoaderDomain> listDomains();
Collection<ClassLoaderPolicy> listPolicies();
Collection<ClassLoaderPolicy> listPolicies(String domainName);

// Your point 2 - class exported in a domain
Class showClass(String domainName, String className);
ClassLoaderPolicy findClassPolicy(String domainName, String className);

// Your point 1 - class exported by a policy
Class showExportedClass(String policyName, String className);
// Class maybe private (not exported)
Class showLocalClass(String policyName, String className);
// Class located using normal rules
Class findVisibleClass(String policyName, String className);
ClassLoaderPolicy findVisibleClassPolicy(String policyName, String className);

One issue with the showLocalClass and showExportedClass
is that the policy may not actually use it, if it is in one of its imports
the imports hide the class (like the uses constraint in OSGi).

I also imagine we can show things like some package queries as well.
Like listing who exports what package and what they are searched for
exportAll.

[starksm64]

You mean locally. That's two different questions depending on whether
it exports those resources/classes.
I also assume you mean a domain or the classloading system?

There's a different question as to whether it can see it from one of its imports
or the domain if it is importAll. But that's just the standard classloading api.

It looks like ClassLoading is best point.

3. What are the classpath elements that are visible starting from a ClassLoader. Sort of a URLClassLoader.toURLs() view.

There's no such thing in general. If the policy is a VFSClassLoaderPolicy
then you can ask what its VFS roots are and you could ask what other policies
it can see that are VFSClassLoaderPolicys or URLClassLoaders.
But the new classloading system has been designed to be flexible.
There's no direct dependency of URLs/VFS etc. Somebody can implement
a policy how they want.

It should not explicitly be URL[], just String[]. In general there needs to be some notion of a classpath. It might be an sql query, who knows, but some generic view should be possible.

[starksm64]

Another thing I would like to get is a directed graph of the domains/policies for a package. An example question to be able to answer is what applications are using what versions of an xml parser implementation.

[adrian.brock]

Another thing I would like to get is a directed graph of the domains/policies for a package. An example question to be able to answer is what applications are using what versions of an xml parser implementation.

That information is already availble on the deployment if you are using
explicit imorts, but it's an implementation detail.
deployment unit -> deployment controller context - > dependeny info -> getDependsOnMe

For the deployments that don't use explicit imports (i.e. importAll) you'd need
to work out if that classloader is the first providing that package in each domain
and assume that all classloaders using "importAll" in that domain are "using" the
xml parser.

[adrian.brock]

There's no such thing in general. If the policy is a VFSClassLoaderPolicy
then you can ask what its VFS roots are and you could ask what other policies
it can see that are VFSClassLoaderPolicys or URLClassLoaders.
But the new classloading system has been designed to be flexible.
There's no direct dependency of URLs/VFS etc. Somebody can implement
a policy how they want.

It should not explicitly be URL[], just String[]. In general there needs to be some notion of a classpath. It might be an sql query, who knows, but some generic view should be possible.

We can ask each ClassLoaderPolicy to implement a getURLs() for management
purposes. For deployment generated classloaders its really just the same as
getClassPath() on the deployment unit. But that doesn't mean that something
should use those URLs as a classpath.

Parts of the filesystem the url represents could be filtered out
e.g.
1) your excluded packages example
2) the OSGi uses constraint where a deployment may contain jms.jar
but declare it as "uses". i.e. it will actually use our jms classes
3) for importAll, a previously deployed classloader may mask some classes
if they appear in two classloaders (only the first gets used)
etc.