[kabirkhan]

I don't like either of these. :-)

Without clearing the black list, the new class is never picked up. Can we include a method to do this in the spi? We would not even need to clear the whole set, just a particular entry. The domain already has a method for this, but I need it on BaseClassLoader.

It shouldn't be blacklisting at all if classes can suddenly appear.
This just needs adding to the ClassLoaderMetaData, i.e. whether
caching and blacklisting can be done for the classloader.

AFAICT we don't know this at the time the classloader is created? So basically we need to turn off blacklisting of all classloaders in jboss 5?

[kabirkhan]

Why aren't the java.* enhancements added to the root classloader?
This would seem like the more sensible location to control overriding standard
classes and it would just be one place to say it always "exports" the default package.

I think I like this idea

[adrian.brock]

AFAICT we don't know this at the time the classloader is created? So basically we need to turn off blacklisting of all classloaders in jboss 5?

What stops you from knowing this?

In practice, for the "importAll" handling, any classloader that has no blacklist
means all subsequent classloaders can't have one either.
(Well actually they can have a local one, but no global one).

A better solution would be if we could "intercept" the defineClass()
and automatically flush the related blacklists.
But unfortunately, the method is "final".

I'm not actually too adverse to this change (it isn't like it is a dangerous operation ;-),
and we already have a mechanism
to bypass the classloading and access the cache on the RealClassLoader
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/trunk/jboss-classloading-spi/src/main/org/jboss/classloading/spi/RealClassLoader.java?revision=64506&view=markup
for the potential performance gain, so adding a flush{cache|blacklist} mechanism
to the RealClassLoader spi wouldn't be that big a change.

Why I don't like it, is that there can be a local blacklist and a global blacklist.
Turning off the blacklist after the classloader has been created and added to the
domain could leave the global one in an inconsistent state unless extra steps
are taken to flush it.

It seems to me that flushing the blacklists
(whenever you define a class outside the normal classloading mechanism)
is better than turning it off altogether?

[adrian.brock]

Why I don't like it, is that there can be a local blacklist and a global blacklist.
Turning off the blacklist after the classloader has been created and added to the
domain could leave the global one in an inconsistent state unless extra steps
are taken to flush it.

This can get even more complicated where you have stacks of domains
caching the results of parent domain lookups. Any flush on the parent
would meaning flushing all the children as well.

This complication is actually avoided in the current implementation
because it doesn't cache the parent result. It assumes the parent will do it
if it is required.

[kabirkhan]

AFAICT we don't know this at the time the classloader is created? So basically we need to turn off blacklisting of all classloaders in jboss 5?

What stops you from knowing this?

We have a new deployment, and create the classloader. At this stage we have no idea what classes are contained nor whether any of these will match any aspects deployed.

I am not arguing for turning off the blacklist completely, I was just pointing out that as far as I can see without the ability to flush the blacklist I could not see any other way.

I think you said that adding a flush method is OK? :-) Should the whole blackList be cleared, or just a single entry?

void flushBlackList();

or

void flushBlackList(String classname);

I think the second option will suffice for my needs

[adrian.brock]

Don't forget that any changes to the RealClassLoader need doing to
BaseClassLoader and the RepositoryClassLoader and that both need
to flush any global cache in the domain/repository they belong to.

I think just flushing a single class or resource url should suffice?