Ales Justin wrote:
This sounds too much of an impl detail to be left to external (non-Classpool) libs to handle.
Hence my suggestion is to make this a spi/configuration on Classpool side,
so users (other libs) don't have to think about it when using it -- they simply use what Classpool provides.
In that case, I assume that the best option is:
(...) keeping ClassPoolRepository the way it is, getting rid of JBossClDelegatingClassPoolRepository, and having the ClassPoolFactory providing a plugin class containing the extra steps required for classloader registration.
This way, from an external point of view, all you have to do is: always use ClassPoolRepository; inject your ClassPoolFactory into ClassPoolRepository.
I implemented a first version of this as part of issue CLASSPOOL-2, which added to the spi package:
- a new interface, ClassLoaderRegistryHandler, responsible for handling the register and unregister calls in ClassPoolRepository
- a ClassLoaderRegistryHandlerFactory interface, that can be implemented by ClassPoolFactories that require a non-default ClassLoaderRegistryHandlers
That way, ClassPoolRepository.setClassPoolFactory checks for whether the CPFactory implements ClassLoaderRegistryHandlerFactory. If it does, ClassPoolRepository uses the factory to create a new ClassLoaderRegistryHandler for itself.
Plus:
- JBossClDelegatingClassPoolRepository has been renamed to JBossClRegistryHandler, is no longer a public class, and implements ClassLoaderRegistryHandler
- JBossclDelegatingClassPoolFactory implements ClassLoaderRegistryHandlerFactory so it can provide JBossClRegistryHandler to ClassPoolRepository
Let me know what you think of this implementation and what do you think should be changed/improved.