aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Osborne (JIRA)" <>
Subject [jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
Date Thu, 22 Oct 2009 13:27:59 GMT


Andrew Osborne commented on ARIES-28:

Adding beanprocessors during a NamespaceHandler invocation sounds like an interesting idea,
although possibly it's a realization that the two concerns can be closer related than the
current interfaces allow. It's entertaining to play with the idea of a NamespaceProcessor,
that integrates both roles, although that's certainly outside the scope of this work. (It
may be something to return to later, when considering new extensions of ComponentMetadata).

I'm really looking with this bit of work (and JIRA-26/27) to lay the groundwork for a few
bits of function, dynamic scopes, and declarative transactions.. Each seperate concerns, but
both satisfiable by the BeanProcessor exit. 

For declarative transactions, looking to introduce a layer that would intercept invocations
to the bean. I was hoping to do this by publishing a BeanProcessor to the registry, to be
discovered by the blueprint impl, and would cause created Bean's to be wrappered with the
appropriate interceptors before init.

It's quite possible that interceptors will be required in the most generic case, (ie, trace/log
of bean functions), where the user wouldnt be expected to configure them from the application.

For the dynamicscopes, I think this may need more discussion, as I find the spec a little
unclear as to how it suggests to extend the scope support, certainly the text indicates it
should be extensible, but the schema seems to indicate otherwise. 

That said, the intent was to use the discovered BeanProcessor (in conjunction with the additional
metadata passed by JIRA-27), to allow the implementation of additional scopes. The bean processor
would spot the scope in the metadata (say, "session", or "request"), and would swap the bean
with a wrapper that appropriately managed the delegation & instantiation.

The issue here is scope is a blueprint attribute, so NamespaceHandlers wouldnt get a chance
to intervene. 

Thoughts/Suggestions ?

> Allow extenders of blueprint to function without requiring specific declaration in deployed
blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>                 Key: ARIES-28
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>          Components: Blueprint
>            Reporter: Andrew Osborne
> Problem:
> BeanProcessors (in conjunction with NamespaceHandlers) are useful to supplement or extend
Blueprint processing. However, unlike NamespaceHandlers, BeanProcessors must currently be
declared in the blueprint xml itself. This would mean that where Blueprint is extended through
the BeanProcessor approach, that every blueprint xml would require updating to make use of
the new function.
> Proposal:
> Like Namespace Handlers, to allow BeanProcessors to be declared in the ServiceRegistry,
as well as in the blueprint xml. 

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

View raw message