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:
class ResourceModuleProvider implements ModuleProvider {
ResourceModuleProvider( Resource resource, [ Parser parser ] ) {...}
ResourceModuleProvider( List resources, [ Parser parser ] ) {...}
List getModuleDescriptors() {...}
}class ClasspathModuleProvider extends ResourceModuleProvider
ClasspathModule(ClassResolver resolver, String resourcePath, [ Parser parser ] ) {...}
}
class FileListModuleProvider extends ResourceModuleProvider
ClasspathModule(ClassResolver resolver, String[] files, [ Parser parser ] ) {...}
}
Alternatively a parser factory could be used, that produces the correct parser
by the file extension.
Achim Huegen
Am Tue, 7 Sep 2004 07:38:47 +0200 schrieb Knut Wannheden <[EMAIL PROTECTED]>:
I like this breakup! Expanding on this, how about splitting the ClasspathModuleProvider into a XmlModuleProvider and a ClasspathXmlModuleProvider:
class XmlModuleProvider implements ModuleProvider { XmlModuleProvider(Resource resource) {...} XmlModuleProvider(List resources) {...} List getModuleDescriptors() {...} }
ClasspathXmlModule would just be responsible for iterating over a classpath (using a ClassResolver) and delegate to XmlModuleProvider for parsing.
--knut
On Mon, 06 Sep 2004 22:38:53 +0200, Achim Huegen <[EMAIL PROTECTED]> wrote:I think a refactoring does make a lot of sense here.
IMO RegistryBuilder knows too much about finding module descriptors and
about their format.
The search for "META-INF/hivemodule.xml" and the xml-processing should be
shifted
to specialized classes.
I could imagine these responsibilities:
// Providers supply a list of ModuleDescriptors to the registryBuilder public interface ModuleProvider { public List getModuleDescriptors(ErrorHandler errorHandler, RegistryAssembly assembly); }
// RegistryBuilder accepts a list of ModuleProviders in constructRegistry
public class RegistryBuilder
{
public constructRegistry( List providers ) {
// calls getModuleDescriptors() on all providers
// and adds them by calling processModule
}
}
// Provider that searches for XML-Descriptors in classpath // default path is "META-INF/hivemodule.xml" (configurable) // Logic from RegistryBuilder#processModules and processModulesResources // is moved over here public class ClasspathModuleProvider implements ModuleProvider { public ClasspathModuleProvider(ClassResolver resolver, String resourcePath) public List getModuleDescriptors(ErrorHandler errorHandler, RegistryAssembly assembly); }
This would allow the easy implementation of additional providers, which
read modules from a database, jndi, or just work on an array of filenames:
For example the implementation of
HiveMindTestcase#buildFrameworkRegistry(String[] files)
could look like this:
{
ModuleProvider provider = new FileListModuleProvider( files );
return builder.constructRegistry(provider);
}
Achim Huegen
--------------------------------------------------------------------- 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]
