aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <timothyjw...@apache.org>
Subject RE: Support for interceptors?
Date Mon, 14 Nov 2011 11:02:34 GMT





Hi,

It is possible to use Service Hooks to hide the original services and publish proxied ones
that you want people to use, however I would regard this as a very risky approach. Firstly,
it is difficult to write a Service Hook correctly without accidentally breaking the service
registry, accidentally filtering the wrong events can make things go badly wrong. Secondly
it creates a very unpleasant ordering requirement (which is a bad thing in OSGi). If your
hook is registered after one of the services it should have been filtering then there may
be bundles using it already. At this point hiding the service from those clients prevents
them finding out when the service goes away.

There's quite a good blog post about Service Hooks here: http://www.osgi.org/blog/2009/02/osgi-service-hooks.html
which explains why they aren't for the faint hearted. I would strongly recommend using blueprint
instead, mostly because it's simpler to implement, but also because it won't break anything
else if it goes wrong, and it will reliably work in any ordering scenario.

As for your worry about dynamism, interceptors are not a static model. You can change the
behaviour of your interceptor every time it is called (if that's what you want). You could
stop logging, starting transactions, counting invocations, or whatever you are doing with
your aspect, at any time then start doing it again later if you want.

My personal recommendation would be to avoid service hooks for this sort of use case, particularly
when Aries blueprint already offers you a proxied, intercepted service model.


Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------


Subject: RE: Support for interceptors?
Date: Mon, 14 Nov 2011 09:50:25 +0100
From: Frederik.DeBacker@dexia.com
To: user@aries.apache.org










Hi all,
 
Thx for the response. I had started looking into the spec and was 
thinking to use the Service Hook specs to solve this. What is your opinion about 
using this approach? I guess the advantage could be that we can put the proxy 
implementation in a separate bundle and that we can deploy/activate 
this dynamically without having to change the 'to be proxied' 
service.
 
thx and kr,
 
Frederik.



From: timothyjward@hotmail.com 
[mailto:timothyjward@hotmail.com] On Behalf Of Timothy 
Ward
Sent: vrijdag 11 november 2011 16:33
To: 
user@aries.apache.org
Subject: RE: Support for 
interceptors?



Hi Frederik,

As Graham says, the way to implement this is 
with a namespace handler. If you create your own namespace then you can add an 
element (or attribute) in the service you want to be intercepted.

The 
namespace handler can then do something like this:

public Metadata 
parse(Element elt, ParserContext pc)
    
{
        Metadata m = 
pc.getEnclosingComponent();
        

        ComponentDefinitionRegistry cdr = 
pc.getComponentDefinitionRegistry();
        

        Interceptor interceptor = 
getMyInterceptor();

        if(cm 
instanceof 
ServiceMetadata)
            
cdr.registerInterceptorWithComponent(cm, 
interceptor);
        
else
            throw 
new RuntimeException("Not a service 
component");

        return 
null;
    }

I hope this is helpful, it seems like 
you're using some pretty advanced blueprint, may I ask what it's for?

Tim 
Ward
-------------------
Apache Aries PMC member & Enterprise OSGi 
advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------



> Date: Fri, 11 Nov 2011 09:20:06 +0000
> Subject: Re: Support for 
interceptors?
> From: gcharters@gmail.com
> To: 
user@aries.apache.org
> 
> Hi Frederik,
> 
> The way to 
get interceptors involved in Blueprint is to add a
> namespace handler. 
This is something that processes a blueprint
> namespace extension. So you 
would define a namespace that you would
> add to blueprint, and maybe an 
associated element that you would
> include to identify the services to be 
intercepted, and then your
> namespace handler would be engaged and have 
the opportunity to do its
> work.
> 
> Apache Aries has a 
number of examples of this (e.g. JPA,
> Transactions). I'd probably start 
by taking a look at the one for
> transactions: 
https://svn.apache.org/repos/asf/aries/trunk/transaction/transaction-blueprint/
> 

> I hope this helps.
> 
> Regards, Graham.
> 
> 
On 10 November 2011 06:48, De Backer Frederik (DBB)
> 
<Frederik.DeBacker@dexia.com> wrote:
> > Hello all,
> 
>
> > I am wondering if the OSGi Enterprise specification has some 
support to
> > define interceptors on OSGi service methods. Suppose for 
example that I want
> > to log the request parameters of a method, is 
it possible to define an
> > interceptor in the blueprint.xml method on 
the service definition. I guess
> > not because I haven't found 
anything until now. Is there some recommended
> > approach to implement 
this? For example, by using an AOP framework like
> > aspectj or using 
spring annotations (however in the last case I don't how
> > how it is 
possible to define the annotations since I would need another
> > 
spring-beans.xml file to define my annotations, next to my blueprint.xml
> 
> file). Has someone done any work on this?
> >
> > Thx a 
lot for the assistance and kind regards,
> >
> > 
Frederik.
> >
> > 
-------------------------------------------------------------------------
> 
> Dexia disclaimer:
> >
> > 
http://www.dexia.com/maildisclaimer.htm
> > 
-------------------------------------------------------------------------
> 
>
> >
-------------------------------------------------------------------------
Dexia disclaimer:

http://www.dexia.com/maildisclaimer.htm
-------------------------------------------------------------------------


 		 	   		  
Mime
View raw message