> It will - see the ClassUtils implementation. It discovers the Class > in the appropriate mechanism to ensure the context class loader is > used first and then the system class loader if not found. This order > of operations works in all environments thus far (JEE and non), and is > the same way we do EhCache discovery.
I was careful to look at the ClassUtils implementation before posting, and yes I understand what the code is doing. However, this still only searches the context class loader and the system class loader, which leaves out a whole bunch of custom classloaders that might be in the system. > Yes, the JCL class loader problems are due to runtime resolution of > *Log* instances based on the argument class, i.e. > > Log log = LogFactory.getLog( getClass() ); This is the reason for *some* of JCL's problems, but if it was the only reason, surely it would have been fixed by now and people would have stopped moving over to SLF4J? I'm not saying that the JSecurity logging API is going to throw exceptions around left, right, and centre, but I do believe it has the potential for anomalous behaviour because of its runtime discovery of classes. I think that if JSecurity were to unexpected log via the JDK logger, then that would be a serious problem for users. If JSecurity were a framework or application with some control over the classloaders, then this wouldn't really be an issue. But it's a library that could be used anywhere. Also, the cache provider API would indeed suffer exactly the same problems (if there are any), although caches are currently less ubiquitous than logging. Anyway, I'm not saying that there are definitely problems with the runtime discovery used, but the implications if there are outweigh the potential benefits in my view, and I haven't seen any evidence to assuage my concerns. Maybe I'm just an old fuddy-duddy, but that's my prerogative :) Cheers, Peter
