The new construct in [clazz], ClazzLoaderFactory is not necessarily an intuitive addition. For some people it may be an indication that [clazz] is becoming too complex. I think I need to explain its purpose.
The considerations are as follows: 1. Some ClazzLoaders are based on reflection, some are not. This is why ClazzLoader APIs are based on the class name. We cannot use Class instead, because some Clazzes are not associated with a Class. 2. If we don't have a Class, we cannot perform reflection. Therefore, we need to obtain a Class by name. Every time this happens we run into problems. We need a ClassLoader, but there is no easy way to find one. 3. When the developers of the JDK encountered a similar problem, they added a method that would give them the caller's class loader. They made the method native and private. With that mechanism Sun's engineers make methods like "Class.forName()" work properly. I personally think we need to lobby to get this mechanism opened to the general public, but for now we are out of luck. 4. Since we cannot make the determination automatically, we'll have to create custom solutions for individual situations. 5. It would be nice to build some generic class loader lookup, but I personally do not believe that it is possible. In some environments (app servers, plug-ins to IDEs etc) there are many class loaders, they are created dynamically, even for individual threads, and linked up into intricate networks. These different environments do it differently and will have different caching needs. So, in order to allow for such custom solutions, I have introduced a new delegation mechanism. It is based on a new interface, ClazzLoaderFactory. It declares one method: createClazzLoader(classLoader). The SPI provider implements this interface and registers the implementation with Clazz using a "model key". The implementation may construct networks of ClazzLoaders, some unique to the supplied class loader, some shared, e.g. for any shared parent class loaders. The client does not know anything about the complexity of the clazz loader created by the SPI provider. It obtains a ClazzLoaderFactory by the model key, calls createClazzLoader, caches the created ClazzLoader and uses it to acquire meta data as needed. As "simple" as that. I could not come up with a simpler solution. Does anybody have an better idea? Please let me know, I would love to reduce complexity in this area. - Dmitri -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>