What I eventually would like to see is a configurable resourcePath in ClasspathXmlModuleProvider( META-INF/hivemodule.xml as default)
The AggregateModuleProvider is a good idea which crossed my mind too. So I think your draft is the way to go.
How much should we care about backward compatiblity?
The public processModule(s) methods could break some code when they are moved.
Achim Huegen
Am Wed, 8 Sep 2004 00:39:29 +0200 schrieb Knut Wannheden <[EMAIL PROTECTED]>:
On Tue, 07 Sep 2004 13:38:51 +0200, Achim Huegen <[EMAIL PROTECTED]> wrote:Maybe a case, where composition is better than inheritance. Although SDL is resting in peace, the support of both XML and SDL would result in : XmlModuleProvider, SdlModuleProvider, ClasspathXmlModuleProvider and ClasspathSdlModuleProvider.
I would suggest a common ancestor that deals with resources and which expects a parser for resource processing. the parser parameter is optional and the XML Parser is used as default:
I see what you're saying. But isn't this maybe a case of YAGNI? I didn't quite understand all the details of your idea either.
After trying out a few solutions this is what I've come up with (boring bits left out):
class RegistryBuilder {
Registry constructRegistry(ModuleProvider provider, Locale locale) {...}
static Registry constructDefaultRegistry() {...}
}
interface ModuleProvider { List getModuleDescriptors(ErrorHandler handler, RegistryAssembly assembly) {...} }
class ClasspathXmlModuleProvider implements ModuleProvider { ClasspathXmlModuleProvider(ClassResolver resolver) {...} }
class XmlModuleProvider implements ModuleProvider { XmlModuleProvider(ClassResolver resolver, Resource resource) {...} XmlModuleProvider(ClassResolver resolver, List resources) {...} }
class AggregateModuleProvider implements ModuleProvider { AggregateModuleProvider(List providers) {...} }
Note that the constructRegistry() method only accepts a single ModuleProvider (not a List). The idea is that using multiple ModuleProviders should be a quite rare case, where the AggregateModuleProvider can be used instead. If it just weren't such a pain to construct a List with a single element in Java...
I'm thinking if it would make sense to replace the XmlModuleProvider and ClasspathXmlModuleProvider with a single:
class XmlModuleProvider implements ModuleProvider { XmlModuleProvider(ClassResolver resolver) {...} XmlModuleProvider(ClassResolver resolver, Resource resource) {...} XmlModuleProvider(ClassResolver resolver, List resources) {...} }
Thoughts?
--knut
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
