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
Am Mon, 6 Sep 2004 15:23:52 +0200 schrieb Knut Wannheden <[EMAIL PROTECTED]>:
More on the responsibilities of RegistryBuilder... Would it make sense to make two separate objects responsible for the descriptor processing phase and the registry construction phase respectively? This would also make the code better communicate the idea that modules can't be added once a registry is constructed:
processor = new ModuleDescriptorProcessor(); processor.processModules(resolver); processor.processModule(...); builder = new RegistryBuilder(); registry = builder.constructRegistry(processor);
Thoughts?
--knut
On Sun, 5 Sep 2004 23:51:40 +0200, Knut Wannheden <[EMAIL PROTECTED]> wrote:On Sun, 5 Sep 2004 14:17:53 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> Sounds ok to me ... but parsing of sub-modules really is a queue.
> Putting a SubmoduleDesriptor into the ModuleDescriptor is fair, but
> I'm hesistant to let that drive the actual search-and-parse of the
> sub-modules. It's a queue, not simply two passes (since sub-modules
> may themselves have sub-modules).
>
I was thinking that the RegistryBuilder#processModule(ClassResolver, Resource) method should be recursive (not two pass) and drive the parse of submodules (and submodules thereof recursively). This would result in a depth first traversal of the submodule hierarchy instead of the currently employed breadth first traversal. Is it the traversal order you are worried about?
> On the other hand, some of this other post-processing, including > dependencies, lends itself well to a descriptor approach. The whole > point is that, once all parsing has occured, dependencies can be check > is perfectly valid. >
The only other post processing I can find is the linking of schemas to service points and configurations. But this is only postponed if the referenced schema hasn't previously been encountered by the parser. Would it be possible to entirely delay this linking to the registry construction phase? Then the DescriptorParser would not have any dependencies on the RegistryAssembly anymore, which would be nice. Maybe some kind of schema lookup could then also replace the reflection used by the current schema linking. I get a feeling I've spun off too far now ;-)
--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]
