aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From The Dweller <>
Subject Re: Exposing the Parser via a ParserService
Date Thu, 03 Dec 2009 14:35:35 GMT
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.


On Thu, Dec 3, 2009 at 12:55 PM, Mark Nuttall <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message