Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Message-ID: <1339367436.65301262773434353.JavaMail.jira@brutus.apache.org>
Date: Wed, 6 Jan 2010 10:23:54 +0000 (UTC)
From: "Andrew Osborne (JIRA)" <jira@apache.org>
To: aries-dev@incubator.apache.org
Subject: [jira] Closed: (ARIES-26) Allow NamespaceHandlers to store data
 beyond the ComponentMetadata, for use later by BeanProcessors.
In-Reply-To: <496083711.1256056439406.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ARIES-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Osborne closed ARIES-26.
-------------------------------

    Resolution: Not A Problem

As mentioned in previous comment, this issue was to introduce function to support an alternate proposed implementation of interceptors. 

Interceptors are now in aries blueprint, so this issue is no longer required, and there have been no requests for it, so closing it.

> Allow NamespaceHandlers to store data beyond the ComponentMetadata, for use later by BeanProcessors.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-26
>                 URL: https://issues.apache.org/jira/browse/ARIES-26
>             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 Namespace(s).
> In order to provide some simple basic structure, the data is stored as a String->Object Map. 

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