Hi, On 7/28/06, Felix Meschberger <[EMAIL PROTECTED]> wrote:
Hence, I thought that making the class loader to use by the BeanConfig class configurable by extending the class with these methods:
It seems a bit kludgy. I'd like to reiterate my earlier idea of replacing the entire config package in Jackrabbit with an IoC mechanism. Instead of instantiating Config instances and using them to instantiate the actual Jackrabbit components, I think it would make for a more modular design to allow a container (OSGi?) to directly instantiate and compose the components. This would require a bit more refactoring work, but I really think it would pay off in simplifying the architecture and increasing modularity.
A third modification concerns the RepositoryConfig class: This class does not currently extend the BeanConfig class. To also support this class loading functionality for the RepositoryConfig class, I suggest having this class extend BeanConfig, too. While it might not provide anything more than this, it would probably also not hurt, would it ?
The RepositoryConfig class is not used to instantiate the RepositoryImpl, only to carry configuration information to an existing RepositoryImpl instance. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
