aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Osborne (JIRA)" <>
Subject [jira] Commented: (ARIES-26) Allow NamespaceHandlers to store data beyond the ComponentMetadata, for use later by BeanProcessors.
Date Wed, 18 Nov 2009 15:10:39 GMT


Andrew Osborne commented on ARIES-26:

I was proposing this as a way of having Namespace Handlers register Interceptors against BeanMetadata,
(without having a concept of Interceptors within the aries blueprint). Now aries blueprint
has Interceptors, this is no longer needed, I'll close this as not-needed unless someone still
thinks this is worth doing?

> Allow NamespaceHandlers to store data beyond the ComponentMetadata, for use later by
> ----------------------------------------------------------------------------------------------------
>                 Key: ARIES-26
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>          Components: Blueprint
>            Reporter: Andrew Osborne
>            Assignee: Andrew Osborne
> Problem:
> Current NamespaceHandler support allows for NamespaceHandlers to declare support for
a Namespace, when elements from that namespace are met within blueprint xml, the Handler is
called to obtain an instance of ComponentMetadata representing the element. 
> When custom elements are met within Bean, Reference, RefList, Service, ServiceProperties,
the current approach is to invoke the namespace handler for each custom element in turn, passing
the metadata as returned by the previous handler. 
> Namespace handlers may be modifying the content of the passed metadata, and returning
the same instance, or may be wrapping it in a new type.. such as ExtendedBeanMetaData implements
BeanMetaData, to store their additional parsed information. 
> This however rapidly becomes problematic when multiple custom namespaces are present
on the same blueprint entity, eg.
> <bean>
>   ...
>   <custom-a/>
>   <custom-b/>
>   <custom-c/>
> </bean>
> with handlers each for a,b,c that extend the passed metadata by wrapping it with one
of their own, you would result in CustomCMetadata, that's wrappering CustomBMetadata, that
in turn is wrappering CustomAMetadata, that is wrappering the original BeanMetadata.. 
> Aside from the issue that A now has to delve through implementations of Metadata it doesnt
not understand to find it's own metadata, there's also the secondary issue that simply declaring
the custom elements in a different order results in different nesting being used. 
> Proposal:
> To address these issues, the ComponentDefinitionRegistry is enhanced to allow storage
of additional data, for a given ComponentMetdata, keyed by namespace URI. 
> With the example above, the potential chaining is left untouched, to avoid disrupting
any current usage. However, instead of custom-a,b,c using wrappering to store additional data,
they return the original metadata (after potentially querying it, in conjunction with their
own parsed data), and store the extra information directly into the ComponentDefinitionRegistry,
keyed by their custom namespace.
> Later, when a (Bean)Processor runs, it is able to query for if any additional data was
registered for this ComponentMetadata within the Registry for the BeanProcessors associated
> In order to provide some simple basic structure, the data is stored as a String->Object

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message