I've just discovered that UserDefinedClassLoaderTestCase is failing for ages now and nobody ever noticed because another failure happens when Junit is printing the report.

I've just fixed the initial failure, but I would also like to prevent the second failure to happen (i.e., if there is a failure, we want to to make sure we see that failure reported).

The cause of that second failure is an OutOfMemoryError, result of an endless instrumentation loop JBoss AOP enters because of calls to logger in JoinPointGenerator. Whenever such a call is found, JBoss AOP tries to weave the class. Since there was a problem in the classloader used by the test (fixed now), the class is not found and the same JoinPointGenerator try to log an error again, entering a infinite loop state.

Another problem that I saw is that, when Junit tries to generate the report, it uses org.junit packaged classes to do so, and JBoss AOP enters the loop again.

Despite the particularities of the aforementioned test, that was buggy, I think we should avoid weaving classes from those packages. Doing otherwise can:

- cause several deadlock problems because AOP startes the weaving process from inside the weaving process, in the case of org.apache.log4j (as seen before with other classes)

- cause problems when somebody is running a test that involves JBoss AOP with Junit, in the case of org.junit.

Can I add those packages to the isNonAdvisableClassName methods?