There's some issues with this proposal.

1) The domain wouldn't be a very easy place (administratively) to register this behavour.
ClassLoading Domains are created dynamically as required.
A better place to register a "ClassNotFoundHandler" would be on the ClassLoading System.
This is where AOP registers its Transformer when running in its old legacy mode.

2) The way the IIOP WebCL processing is done now is incorrect in my opinion.
If you are going to generate a stub then it should be defined against the same
classloader as the interface. Otherwise you'll get memory leaks.
This will effectively require a double lookup, once to determine there
is no stub class and a second one to find the interface.

e.g. with the current ejb stub generation, each ejb jar gets its own
WebCL and each will generate its own copy of the stub (not visible to
other applications and potentially leaking the interface reference
if things don't get redeployed properly).

3) The way the classloaders currently work is that they first check
for the class resource existing.
i.e. It effectively does a
ClassLoader.getResource("com/acme/Whatever_Stub.class")
before going onto the other classloading processing (which requires a lot of
complicated dancing around because of the Sun classloader problems).
If the resource doesn't exist, the classloader is not considered/used.

"sguilhen@redhat.com" wrote:

As Adrian said, we can always include the stub classes in the vehicles war deployments to have the tests passing, but it would be good to have a more general solution in place.

"adrian@jboss.org" wrote:

2) The way the IIOP WebCL processing is done now is incorrect in my opinion.
...
3) The way the classloaders currently work is that they first check
for the class resource existing.

public Class<?> loadClass(...)
{
 Class<?> result = current classloading code
 if (result == null)
 result = runClassNotFoundHandlers(this, ...);
 if (result == null)
 throw ClassNotFoundException(...);
 return result;
}