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]
