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.debac...@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: timothyjw...@hotmail.com
[mailto:timothyjw...@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: gchart...@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.debac...@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
-------------------------------------------------------------------------
