[jira] Created: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
---------------------------------------------------------------------------------------------------------------------

                 Key: ARIES-28
                 URL: https://issues.apache.org/jira/browse/ARIES-28
             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768165#action_12768165 ]

Guillaume Nodet commented on ARIES-28:
--------------------------------------

One thing I would really dislike is to end up with a blueprint bundle that have a different behavior depending on the state of the osgi framework.  I'm not sure what you have in mind, but automatic processing of beans without anything in the blueprint xml /  bundle to indicate so would be plain wrong imho (and against the spec).

FWIW, namespace handlers *have* to be declared in the xml, else they won't be used, so I hope you have something like that in mind.

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768184#action_12768184 ]

Andrew Osborne commented on ARIES-28:
-------------------------------------

Namespace Handlers are not declared in the xml, but elements that are from custom namespaces managed by the Namespace Handler are.

The Namespace Handlers are picked up from the osgi service registry, as services that implement org.apache.aries.blueprint.NamespaceHandler (with an associated property to declare the uri's of the namespaces they support).

When elements from a non-blueprint namespace are met, the current set of registered NamespaceHandlers is checked for support for the namespace encountered, if one claims to support it, then the element is processed via it, otherwise exceptions are thrown indicating the element was unsupported.

I take the aim of this, is to allow Blueprint xml to be extensible, with elements from other namespaces, and to have the blueprint bundle be able to find and work with handlers.

It's this approach that I wish to extend to BeanProcessors, (ideally all Processors), to allow other bundles to contribute to the Blueprint processing, specifically to the Bean creation.

Neither NamespaceHandler, nor BeanProcessor form part of the current BlueprintSpec, I believe NamespaceHandler was removed from it quite late, and BeanProcessor I hadnt seen before I met this blueprint codebase.

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768194#action_12768194 ]

Guillaume Nodet commented on ARIES-28:
--------------------------------------

Let me rephrase my thoughts a bit.

In a number of places, the spec  makes room for extensions.  Such extensions have to be explicitely enabled by the user in order to leverage those.  This includes custom namespaces.

What I really would not want, is to have a blueprint bundle behave differently depending if a BeanProcessor has been registered in the OSGi registry or not.   I want to user to be aware of any processing by enabling it explicitely somehow.  This ensure that users don't rely on anything non portable without being aware of that.  That's currently the case for all extensions in our blueprint implementation, as they are all enabled by using a custom namespace somehow.  

That said, I think it's not sufficient either.  I do agree we could make use of bean processors registered in the OSGi registry, but I think the user should enable a bean processor somehow explicitely.   And in doing so, I'm not quite sure if we really need to have those processors registered in the OSGi registry anymore.   For example, if you have a custom namespace handler that defines a bean processor which should be applied, you'd have to enable that using for example an attribute on the blueprint element:

<blueprint tx:use="true" xmlns:tx="xxx"> ...

When the custom namespace handler for the tx prefix is called to parse the "tx:use" attribute, it could register the bean processor in the blueprint context.

So, could you give a bit more details ?



> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768679#action_12768679 ]

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: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769115#action_12769115 ]

Guillaume Nodet commented on ARIES-28:
--------------------------------------

My understanding of custom scope leads me to think they should be declared in the following way:

{code}
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
                 xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
                 ext:useCustomScopes="true">

    <bean scope="ext:customScope" ...>
       ...
    </bean>
</blueprint>
{code}

The scope attribute is either "singleton", "token" or a qualified name.  For custom scopes we need to use qualified names, hence the declaration of the xmlns:ext namespaces.  In addition, in order to use custom extensions in the blueprint definition, we need to force the user to declare those, so that's why i've added the ext:useCustomScopes attribute.  This is just an example, but my main point in order to use extensions to the spec, the user has to do that on purpose.  The use of a custom namespace attribute forces the user to explicitely tie its blueprint xml definition to a custom extension.   If we were to just allow the use of scope="session" for example, the user would not really be aware that he's relying on custom extensions that may not work on other blueprint implementations.

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768679#action_12768679 ]

Andrew Osborne edited comment on ARIES-28 at 10/23/09 2:18 PM:
---------------------------------------------------------------

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 ARIES-26 / ARIES-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 ARIES-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 ?

[edited to correct JIRA-XX to ARIES-XX]



      was (Author: ozzyjira):
    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 ARIES-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: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769228#action_12769228 ]

Andrew Osborne commented on ARIES-28:
-------------------------------------

I think that's the same thought I'd reached about custom scopes, except for the requirement to add an attribute.. That feels a little more like it's specific to how we're handling the implementation, as it's the part that would cause a namespace handler to actually be invoked.

I guess the secondary issue with the scope extension is that using a namespace for an attribute value is a little application specific, by that I mean that although namespaces are associated with elements, and attributes as part of XML, they are not normally seperately associable to attribute values. This is reflected in most XML api's, which only offer the attribute value as string. That said, I've seen it used before in other places, so we wouldnt exactly be too unique in continuing the practice.

If we accept that scope is to allow namespace prefixed values, then it shouldnt be too hard to have the Parser initiate some call out to the Namespace Handler that's claiming the associated namespace. We'll have to do the legwork of dereferencing the namespace prefix back to a namespace. Overall, it doesnt fit the current NamespaceHandler model entirely, as that's centered around parsing attributes & elements, rather than handling attribute values. But that's not too difficult to fix if we need to. It does tend to lean rather toward being a special case just for Scope however, so possibly should become it's own Handler, rather than becoming another aspect of the NamespaceHandler.

As for the interceptors described above, I guess they could be enabled by using an attribute, that causes a NamespaceHandler to come along, that pushes a BeanProcessor into play. Alternatively, we look at making the interceptor concept part of the Blueprint impl, so that it's always there to behave the same.. Issue then becomes how we plug in interceptors, to the blueprint impl, as if we want to have any sort of configuration as to how an interceptor affects processing, it's sounding more like that would have to be in a users xml, which doesnt feel right for what is container level configuration.. of course, acknowledging that container level configuration could exist would imply that not all instances of the container will act identically, which starts to head back to your point of not wanting blueprint to act differently based on the state of the framework..

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768679#action_12768679 ]

Andrew Osborne edited comment on ARIES-28 at 10/23/09 2:17 PM:
---------------------------------------------------------------

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 ARIES-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 ?



      was (Author: ozzyjira):
    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: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769251#action_12769251 ]

Guillaume Nodet commented on ARIES-28:
--------------------------------------

I think the intent of section 121.3.3 of the blueprint spec was to force the use of the namespace in an attribute or element to enable any extension to the spec.  I think that custom scopes fall into this category ...

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770094#action_12770094 ]

Andrew Osborne commented on ARIES-28:
-------------------------------------

Ok.. so having spent a while considering this.. I'm not sure this feature will be required anymore..

As I've said above, the intent here was to enable 2 functions, interceptors, and dynamic scopes.

Dynamic scopes, I think we've arrived at the conclusion that a custom scope will be required to be a properly defined namespace prefixed value. This is distinct enough to warrant a seperate feature. The parser would need updating to notice when scopes were non-blueprint namespaced, at which point the NamespaceHandler can be invoked for the declared scope namespace. A first pass implementation can use that invocation to inject a BeanProcessor that can subsequently implement the scope. This solution isnt perfect, as the BeanProcessor would be called for all beans, and would have to query the BeanMetadata to discover if the scope is one it wishes to act for. This can be fixed somewhat by perhaps introducing a ScopedBeanProcessor, that would only be invoked for scopes it registers against.

Interceptors, can be solved similarly. Interceptor would be introduced, as an interface like BeanProcessor, where beans can be declared in the XML with an attribute that declares them as interceptors. (Or also, injected directly to the ComponentDefinitionRegistry by a namespace handler, in response to being invoked to handle a custom namespace). Again, this is distinct enough to warrant its own feature. The key difference between an interceptor and a BeanProcessor, is the BeanProcessor is intended to allow modification of the Bean creation/init/destroy logic, where as the Interceptor is intended to allow notification of Bean method invocation, by pre-call, post-call. Interceptors should not modify arguments, or return values from the method invocations.

I'm having a quiet hack toward seeing if the above 2 can work.. if the results are favorable, I'll raise features for them. At least by attempting them, I'll learn any blocking issues. I appreciate any early feedback / comments though =)

That leaves the generic, or 'default' interceptors, that wish to be present for all invocations. Do you have any thoughts on these? I can try to explain these further if needed.

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/ARIES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775395#action_12775395 ]

Andrew Osborne commented on ARIES-28:
-------------------------------------

Quiet hack a success =) I'll raise 2 new issues for the dynamic scopes & interceptors..

As the intent of this issue was to enable those 2 (excluding generic/default interceptors) .. I think this issue should be closed out as no longer required.

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             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.

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (ARIES-28) Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

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

Andrew Osborne closed ARIES-28.
-------------------------------

    Resolution: Won't Fix
      Assignee: Andrew Osborne

Closing this issue, as it's goals have been moved to be implemented by other features. (ARIES-46 and ARIES-47), which will not require BeanProcessors to be locateable via the service registry.

> Allow extenders of blueprint to function without requiring specific declaration in deployed blueprint components xml.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-28
>                 URL: https://issues.apache.org/jira/browse/ARIES-28
>             Project: Aries
>          Issue Type: Improvement
>          Components: Blueprint
>            Reporter: Andrew Osborne
>            Assignee: 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.