Hmm.. have given this some thought, and I'm not entirely in support of the idea of introducing the LiveComponentDefinitionRegistry.
The getter methods were added to support a scenario where a namespace handler was creating passthrumetadatas. As these metadatas are acting like mini component factories, they needed access to instances like the blueprint bundle context, or converter.. As we found the instances were already present in the ComponentDefinitionRegistry we could pull them out, but as described in the jira, it felt wrong to rely on that kind of internal knowledge, so we added the getters. Now, having a parser service sounds really quite useful, I can see a number of scenarios where it would be beneficial to ensure that another view of the blueprint in a bundle is consistent with the containers view. However, introducing a parser service does raise an important question regarding namespace handlers in general. Currently when a ns handler is invoked, it can safely assume it is being called as part of a potential setup for a blueprint container (only potential, as the setup could still throw a ComponentDefinitionException). With a parser service present, some parses will be 'just' to create a component definition registry. For a parser service to retain its value, I think the ns handlers must just perform their job, and not end up doing one thing for a 'real' parse, and another for a 'parser service' parse. With that said, I can explain now why I disagree with the LiveComponentDefinitionRegistry, once introduced, it would potentially split the way that ns handlers 'could' work, something that we do not have to be too concerned with currently. So, I think in retrospect, adding the getters to the ComponentDefinitionRegistry was a mistake, that instead, an interface with those methods, should be passed to the 'getObject' method of passthroughmetadata, to enable the implementation to use them as required, without the values being involved or required during the parse phase. This way, namespace handlers get a single environment to consider when executing, and passthroughmetadata gains the ability to allow it's instance access to the current blueprint objects. Regards, Ozzy On Thu, Dec 3, 2009 at 12:55 PM, Mark Nuttall <[email protected]> wrote: > We've a need to parse blueprint xml on behalf of an external, broadly > administrative client application. I propose to have the > BlueprintExtender publish a service, > > public interface ParserService { > ComponentDefinitionRegistry parse (List<URL> urls, Bundle > clientBundle) throws Exception; > ComponentDefinitionRegistry parse (List<URL> urls, Bundle > clientBundle, boolean validate) throws Exception; > } > > in the course of prototyping this we realised that the recent changes > to the ComponentDefinitionRegistry constructor make this difficult to > do. Our proposed change is to extend the ComponentDefinitionRegistry > interface and ComponentDefinitionRegistryImpl class both, via a new > interface, > > public interface LiveComponentDefinitionRegistry extends > ComponentDefinitionRegistry { > BlueprintContainer getBlueprintContainer(); > Bundle getBlueprintBundle(); > BundleContext getBlueprintBundleContext(); > Converter getBlueprintConverter(); > } > > The point here is that NamespaceHandlers, if they wish to use these > methods, must use the LiveComponentDefinitionRegistry interface, so > acknowledging that they are operating on a running, or Live > ComponentDefinitionRegistry, and not one that we've created just to > hand back to a client of a ParserService. > > Do let me know if you've objections. > > Regards, > > Mark >
