You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Ivanhoe Abrahams <iv...@gmail.com> on 2010/03/30 11:14:30 UTC
AOP in Apache Felix
Hi all
I am looking around for the "correct" way for using AOP in OSGI.
I dont have concrete examples right yet, but basically I would eventually
want to use either Load time weaving OR dynamic proxies,
preferably with AspectJ, but I dont mind using other AOP frameworks....
However I do want to use it in a way that is "standard", in other words it
should work in at least Felix and Equinox and others if possible.
I see there is already a a thread discussing AOP and Felix but it does not
seem to give any answers.
Google also does not provide any goodness on this topic. At lest not that I
have found.
So what would be the correct way to implement AOP in OSGI based an system?
Thank you in advance
Ivanhoe
Re: AOP in Apache Felix
Posted by Guillaume Nodet <gn...@gmail.com>.
Depends what you want. Remember in OSGi, the same bundle can be used in
multiple "applications".
When you write a web app, all the jars you use are inside your web app and
another web app won't use your jars.
That's not the case in OSGi, so if you want an application to use some AOP
on a given bundle, the effect would be global.
That could be a problem too.
So knowing who is the requester can have some value. And service hooks can
provide that afaik.
On Wed, Mar 31, 2010 at 11:29, Guo Du <mr...@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 10:12 AM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> > Wouldn't it make more sense to use service hooks instead ?
> > The current design is limited as if a user wants to grab the list of
> > services and use those, that would not work.
> >> > Option 2 is intercepting the calls and dynamically weaves in
> >> > code...something akin to asm bytecode weaving?
> The approach looks like some kind of hacking. For proper AOP :) the
> service should be intercepted in first place before publish.
>
> -Guo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: AOP in Apache Felix
Posted by Guo Du <mr...@gmail.com>.
On Wed, Mar 31, 2010 at 10:12 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Wouldn't it make more sense to use service hooks instead ?
> The current design is limited as if a user wants to grab the list of
> services and use those, that would not work.
>> > Option 2 is intercepting the calls and dynamically weaves in
>> > code...something akin to asm bytecode weaving?
The approach looks like some kind of hacking. For proper AOP :) the
service should be intercepted in first place before publish.
-Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AOP in Apache Felix
Posted by Guillaume Nodet <gn...@gmail.com>.
The comment was more directed as Marcel ;-)
Service hooks are new in OSGi Core 4.2 and can be used to have a closer
interaction with the service engine.
Use cases as depicted in the core spec includes:
* service proxying
* providing services on demand
So what Marcel did falls exactly into this category. Service hooks can be
used to completely hide the original service
and provide a proxied service instead (where you can then perform anything
you want).
Note that this is a very low level tool provided by the OSGi framework.
On Wed, Mar 31, 2010 at 11:19, Ivanhoe Abrahams
<iv...@gmail.com>wrote:
> Hi Guillaume
>
> Can you give more information on service hooks? Is this something new or
> are
> you talking about ServiceTracker stuff?
>
> thnks
> Ivanhoe
>
>
> On Wed, Mar 31, 2010 at 11:12 AM, Guillaume Nodet <gn...@gmail.com>
> wrote:
>
> > Wouldn't it make more sense to use service hooks instead ?
> > The current design is limited as if a user wants to grab the list of
> > services and use those, that would not work.
> >
> > On Wed, Mar 31, 2010 at 11:06, Marcel Offermans <
> > marcel.offermans@luminis.nl
> > > wrote:
> >
> > > On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote:
> > >
> > > > This is helpful in getting me pointing in the right direction.
> > > > So just to recap.
> > > >
> > > > Option 1 in your email is the traditional approach where you have aop
> > > > pointcuts, etc. defined
> > > > Option 2 is intercepting the calls and dynamically weaves in
> > > > code...something akin to asm bytecode weaving?
> > >
> > > It does not do bytecode weaving at all, it relies on the fact that
> > services
> > > have a service ranking, so the aspect simply publishes a service with
> all
> > > the same properties as the original one, but a higher ranking. Clients
> > will
> > > automatically pick the service with the highest ranking. So there's no
> > > bytecode weaving at all (which makes debugging a lot easier, since your
> > code
> > > still looks exactly like you wrote it).
> > >
> > > Greetings, Marcel
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: AOP in Apache Felix
Posted by Ivanhoe Abrahams <iv...@gmail.com>.
Hi Guillaume
Can you give more information on service hooks? Is this something new or are
you talking about ServiceTracker stuff?
thnks
Ivanhoe
On Wed, Mar 31, 2010 at 11:12 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Wouldn't it make more sense to use service hooks instead ?
> The current design is limited as if a user wants to grab the list of
> services and use those, that would not work.
>
> On Wed, Mar 31, 2010 at 11:06, Marcel Offermans <
> marcel.offermans@luminis.nl
> > wrote:
>
> > On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote:
> >
> > > This is helpful in getting me pointing in the right direction.
> > > So just to recap.
> > >
> > > Option 1 in your email is the traditional approach where you have aop
> > > pointcuts, etc. defined
> > > Option 2 is intercepting the calls and dynamically weaves in
> > > code...something akin to asm bytecode weaving?
> >
> > It does not do bytecode weaving at all, it relies on the fact that
> services
> > have a service ranking, so the aspect simply publishes a service with all
> > the same properties as the original one, but a higher ranking. Clients
> will
> > automatically pick the service with the highest ranking. So there's no
> > bytecode weaving at all (which makes debugging a lot easier, since your
> code
> > still looks exactly like you wrote it).
> >
> > Greetings, Marcel
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
RE: AOP in Apache Felix
Posted by Kiev Gama <ki...@hotmail.com>.
Hello,
Please don't take me wrong, but I would call it a "poor man's AOP" :)We cannot explicitly express concepts such as joinpoints, pointcuts or advices. Hooks provide an elegant but limited workaround. Depending on what you need, it may not be enough.I could not find a way to intercept the actual service object being served (i.e. getService). A BindHook proposed in the service hooks specification draft would do that, but it was apparently rejected since it is described as a considered alternative, but not present in the final spec.By using AspectJ I could do that as well as other things I needed, with relative portability since it worked in different versions of Felix, Knopflerfish and Equinox without much effort. However, by doing that you no longer have a standard framework implementation.
I'm not sure if this message helps, but I just wanted to share what I did with AOP on top of OSGi.
Cheers,Kiev
> Date: Wed, 31 Mar 2010 12:30:46 +0200
> Subject: Re: AOP in Apache Felix
> From: ivanhoeabrahams@gmail.com
> To: users@felix.apache.org
>
> Thankyou guys,
>
> I will try and look at both service hooks and @AspectService(ranking=1)...
> I see I still have a bit of information to process to get up to walking
> speed
>
> Ivanbhoe
>
>
> On Wed, Mar 31, 2010 at 11:43 AM, Marcel Offermans <
> marcel.offermans@luminis.nl> wrote:
>
> > On Mar 31, 2010, at 11:12 , Guillaume Nodet wrote:
> >
> > > Wouldn't it make more sense to use service hooks instead ?
> >
> > Service hooks are somewhat less dynamic in that I cannot decide lateron to
> > install them and have them work with "everything that was already in place".
> > This is explained in 12.7.3 about Ordering. I wanted to have this ability,
> > even for services that were already used by clients before the aspect was
> > installed. If you don't need that ability, and don't mind being able to run
> > only on 4.2 frameworks, then service hooks are a good alternative.
> >
> > > The current design is limited as if a user wants to grab the list of
> > > services and use those, that would not work.
> >
> > That depends on how you actually grab that list of course. If you just grab
> > a list of all services of a certain type, that won't work, but it's not
> > actually too hard to pick only the highest ranking service if there are
> > multiple services in the list that otherwise have the same properties. But
> > you are right, this is a little bit more involved and would be simpler if
> > service hooks were used.
> >
> > Perhaps it would be nice to have the option to use service hooks if your
> > trade offs are different and you don't mind having to install the hooks
> > first.
> >
> > Greetings, Marcel
> >
> >
> > >
> > > On Wed, Mar 31, 2010 at 11:06, Marcel Offermans <
> > marcel.offermans@luminis.nl
> > >> wrote:
> > >
> > >> On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote:
> > >>
> > >>> This is helpful in getting me pointing in the right direction.
> > >>> So just to recap.
> > >>>
> > >>> Option 1 in your email is the traditional approach where you have aop
> > >>> pointcuts, etc. defined
> > >>> Option 2 is intercepting the calls and dynamically weaves in
> > >>> code...something akin to asm bytecode weaving?
> > >>
> > >> It does not do bytecode weaving at all, it relies on the fact that
> > services
> > >> have a service ranking, so the aspect simply publishes a service with
> > all
> > >> the same properties as the original one, but a higher ranking. Clients
> > will
> > >> automatically pick the service with the highest ranking. So there's no
> > >> bytecode weaving at all (which makes debugging a lot easier, since your
> > code
> > >> still looks exactly like you wrote it).
> > >>
> > >> Greetings, Marcel
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > > ------------------------
> > > Open Source SOA
> > > http://fusesource.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
https://signup.live.com/signup.aspx?id=60969
Re: AOP in Apache Felix
Posted by Ivanhoe Abrahams <iv...@gmail.com>.
Thankyou guys,
I will try and look at both service hooks and @AspectService(ranking=1)...
I see I still have a bit of information to process to get up to walking
speed
Ivanbhoe
On Wed, Mar 31, 2010 at 11:43 AM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:
> On Mar 31, 2010, at 11:12 , Guillaume Nodet wrote:
>
> > Wouldn't it make more sense to use service hooks instead ?
>
> Service hooks are somewhat less dynamic in that I cannot decide lateron to
> install them and have them work with "everything that was already in place".
> This is explained in 12.7.3 about Ordering. I wanted to have this ability,
> even for services that were already used by clients before the aspect was
> installed. If you don't need that ability, and don't mind being able to run
> only on 4.2 frameworks, then service hooks are a good alternative.
>
> > The current design is limited as if a user wants to grab the list of
> > services and use those, that would not work.
>
> That depends on how you actually grab that list of course. If you just grab
> a list of all services of a certain type, that won't work, but it's not
> actually too hard to pick only the highest ranking service if there are
> multiple services in the list that otherwise have the same properties. But
> you are right, this is a little bit more involved and would be simpler if
> service hooks were used.
>
> Perhaps it would be nice to have the option to use service hooks if your
> trade offs are different and you don't mind having to install the hooks
> first.
>
> Greetings, Marcel
>
>
> >
> > On Wed, Mar 31, 2010 at 11:06, Marcel Offermans <
> marcel.offermans@luminis.nl
> >> wrote:
> >
> >> On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote:
> >>
> >>> This is helpful in getting me pointing in the right direction.
> >>> So just to recap.
> >>>
> >>> Option 1 in your email is the traditional approach where you have aop
> >>> pointcuts, etc. defined
> >>> Option 2 is intercepting the calls and dynamically weaves in
> >>> code...something akin to asm bytecode weaving?
> >>
> >> It does not do bytecode weaving at all, it relies on the fact that
> services
> >> have a service ranking, so the aspect simply publishes a service with
> all
> >> the same properties as the original one, but a higher ranking. Clients
> will
> >> automatically pick the service with the highest ranking. So there's no
> >> bytecode weaving at all (which makes debugging a lot easier, since your
> code
> >> still looks exactly like you wrote it).
> >>
> >> Greetings, Marcel
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: AOP in Apache Felix
Posted by Marcel Offermans <ma...@luminis.nl>.
On Mar 31, 2010, at 11:12 , Guillaume Nodet wrote:
> Wouldn't it make more sense to use service hooks instead ?
Service hooks are somewhat less dynamic in that I cannot decide lateron to install them and have them work with "everything that was already in place". This is explained in 12.7.3 about Ordering. I wanted to have this ability, even for services that were already used by clients before the aspect was installed. If you don't need that ability, and don't mind being able to run only on 4.2 frameworks, then service hooks are a good alternative.
> The current design is limited as if a user wants to grab the list of
> services and use those, that would not work.
That depends on how you actually grab that list of course. If you just grab a list of all services of a certain type, that won't work, but it's not actually too hard to pick only the highest ranking service if there are multiple services in the list that otherwise have the same properties. But you are right, this is a little bit more involved and would be simpler if service hooks were used.
Perhaps it would be nice to have the option to use service hooks if your trade offs are different and you don't mind having to install the hooks first.
Greetings, Marcel
>
> On Wed, Mar 31, 2010 at 11:06, Marcel Offermans <marcel.offermans@luminis.nl
>> wrote:
>
>> On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote:
>>
>>> This is helpful in getting me pointing in the right direction.
>>> So just to recap.
>>>
>>> Option 1 in your email is the traditional approach where you have aop
>>> pointcuts, etc. defined
>>> Option 2 is intercepting the calls and dynamically weaves in
>>> code...something akin to asm bytecode weaving?
>>
>> It does not do bytecode weaving at all, it relies on the fact that services
>> have a service ranking, so the aspect simply publishes a service with all
>> the same properties as the original one, but a higher ranking. Clients will
>> automatically pick the service with the highest ranking. So there's no
>> bytecode weaving at all (which makes debugging a lot easier, since your code
>> still looks exactly like you wrote it).
>>
>> Greetings, Marcel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AOP in Apache Felix
Posted by Guillaume Nodet <gn...@gmail.com>.
Wouldn't it make more sense to use service hooks instead ?
The current design is limited as if a user wants to grab the list of
services and use those, that would not work.
On Wed, Mar 31, 2010 at 11:06, Marcel Offermans <marcel.offermans@luminis.nl
> wrote:
> On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote:
>
> > This is helpful in getting me pointing in the right direction.
> > So just to recap.
> >
> > Option 1 in your email is the traditional approach where you have aop
> > pointcuts, etc. defined
> > Option 2 is intercepting the calls and dynamically weaves in
> > code...something akin to asm bytecode weaving?
>
> It does not do bytecode weaving at all, it relies on the fact that services
> have a service ranking, so the aspect simply publishes a service with all
> the same properties as the original one, but a higher ranking. Clients will
> automatically pick the service with the highest ranking. So there's no
> bytecode weaving at all (which makes debugging a lot easier, since your code
> still looks exactly like you wrote it).
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: AOP in Apache Felix
Posted by Marcel Offermans <ma...@luminis.nl>.
On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote:
> This is helpful in getting me pointing in the right direction.
> So just to recap.
>
> Option 1 in your email is the traditional approach where you have aop
> pointcuts, etc. defined
> Option 2 is intercepting the calls and dynamically weaves in
> code...something akin to asm bytecode weaving?
It does not do bytecode weaving at all, it relies on the fact that services have a service ranking, so the aspect simply publishes a service with all the same properties as the original one, but a higher ranking. Clients will automatically pick the service with the highest ranking. So there's no bytecode weaving at all (which makes debugging a lot easier, since your code still looks exactly like you wrote it).
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AOP in Apache Felix
Posted by Ivanhoe Abrahams <iv...@gmail.com>.
Thank you Marcel
This is helpful in getting me pointing in the right direction.
So just to recap.
Option 1 in your email is the traditional approach where you have aop
pointcuts, etc. defined
Option 2 is intercepting the calls and dynamically weaves in
code...something akin to asm bytecode weaving?
Once again thankyou for your reply
Ivanhoe
On Wed, Mar 31, 2010 at 9:21 AM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:
> Hello Ivanhoe,
>
> How to best do AOP in an OSGi environment in general is an interesting
> question. I think there's two roads you can take here:
>
> 1) the more "traditional" way of doing AOP with tools like AspectJ,
> instrumenting bundle implementations
>
> 2) AOP at the OSGi service level, "intercepting" existing services and
> adding aspects that way
>
> Both have their advantages and disadvantages, but I am a big fan of doing
> it the last way, because it seems more in touch with the OSGi way of doing
> things: not exposing implementations, only sharing services and their
> versioned packages. So using this mechanism, you can intercept existing
> services and basically add a new service on top of it. By specifying
> priorities you can even chain aspects and determine their ordering and best
> of all, this process is completely dynamic: you can add or remove aspects
> because they can be packaged as separate bundles and even when you update
> underlying services, the aspects will just as happily work on top of the
> updated services.
>
> Actually, I have recently been working on adding support for that form of
> aspect orientation to the Dependency Manager so you can easily add aspects
> to existing services (this is still only available in trunk, not in a
> released version).
>
> An example, let's say use Servlets using the whiteboard pattern and want to
> add an aspect that simply counts the number of invocations to each servlet,
> you could set that up like this:
>
> /** The Bundle Activator for your aspect bundle. */
> public class Activator extends DependencyActivatorBase {
> public void init(BundleContext bc, DependencyManager dm) throws Exception
> {
> dm.add(createAspectService(Servlet.class, null, 1, ServletAspect.class,
> null));
> }
> }
>
> Basically the code above says: for any Servlet service that appears in the
> registry, create an aspect with a service ranking of 1 that is implemented
> by an instance of ServletAspect (that is instantiated for every service).
>
> /** The aspect implementation. */
> public class ServletAspect implements Servlet {
> volatile Servlet m_servlet;
>
> private long m_counter;
> public void service(ServletRequest req, ServletResponse res) {
> synchronized (this) { m_counter++; }
> m_servlet.service(req, res);
> }
> /* implement the other methods of Servlet... */
> }
>
> And this part implements the aspect. It obviously needs to implement the
> same service, and it gets injected with the real service so you can delegate
> to it once you've added whatever you wanted to do in your aspect (such as
> increment a counter in the example).
>
> That's all there is to it.
>
> Greetings, Marcel
>
>
> On Mar 31, 2010, at 8:49 , Ivanhoe Abrahams wrote:
>
> > Hi Teemu
> >
> > Thank you for your reply
> >
> > To be honest, I have not started any experiments yet,
> > No I do not want to instrument the container itself,
> > My immediate experimnent would be to gather some performance
> > metrics/monitoring using AspectJ for my bundles.
> > I think forget about me mentioning dynamic proxies as this is NOT what I
> > want.
> >
> > I was thinking more about problems that others might have encountered in
> > this area, ESPECIALLY classloading restrictions. If any, if there are no
> > real issues in this area the great.
> >
> > In some of the previous messages about this topic there was mention about
> > possibly implementing something similar to the "Equinox-specific hooks to
> > perform load-time weaving" as this was probably also needed for JPA
> hooks.
> > Any informatioon about this would be helpful.
> >
> > Once again, I have not started any experimentation yet.
> > My question is more centered around how to go about this. What are
> other's
> > experience with AOP and OSGI.
> >
> > I am not sure how to start. I am dithering a bit.
> > Ivanhoe
> >
> >
> > On Tue, Mar 30, 2010 at 1:33 PM, teemu kanstren <tk...@gmail.com>
> wrote:
> >
> >> Hello,
> >>
> >> What do you expect to be the difference? What are the results of your
> >> experiments in this regard? Are you instrumenting the container or a set
> of
> >> bundles? You talk about possibility of using a Proxy, what do you plan
> to
> >> use it for?
> >>
> >> I guess some things can depend on your instrumentation code. My guess is
> >> that you could have some classloader issues with multiple bundles
> sharing
> >> some global aspects if you want something like that. But depends on what
> >> you
> >> want to do and also trying it out will tell you the best..
> >>
> >> Teemu
> >>
> >>
> >> 2010/3/30 Ivanhoe Abrahams <iv...@gmail.com>
> >>
> >>> Hi all
> >>>
> >>> I am looking around for the "correct" way for using AOP in OSGI.
> >>> I dont have concrete examples right yet, but basically I would
> eventually
> >>> want to use either Load time weaving OR dynamic proxies,
> >>> preferably with AspectJ, but I dont mind using other AOP frameworks....
> >>> However I do want to use it in a way that is "standard", in other words
> >> it
> >>> should work in at least Felix and Equinox and others if possible.
> >>>
> >>> I see there is already a a thread discussing AOP and Felix but it does
> >> not
> >>> seem to give any answers.
> >>> Google also does not provide any goodness on this topic. At lest not
> that
> >> I
> >>> have found.
> >>>
> >>> So what would be the correct way to implement AOP in OSGI based an
> >> system?
> >>>
> >>> Thank you in advance
> >>> Ivanhoe
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: AOP in Apache Felix
Posted by Pierre De Rop <pi...@gmail.com>.
Hello Ivanhoe;
As an addition to Marcel's response, here is the same version of the Servlet
example, but using DM annotations:
@AspectService(ranking=1)
public class ServletAspect implements Servlet {
volatile Servlet m_servlet; // real/original servlet
private long m_counter;
public void service(ServletRequest req, ServletResponse res) {
synchronized (this) { m_counter++; }
m_servlet.service(req, res);
}
}
Regards;
/pierre
On Wed, Mar 31, 2010 at 9:21 AM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:
> Hello Ivanhoe,
>
> How to best do AOP in an OSGi environment in general is an interesting
> question. I think there's two roads you can take here:
>
> 1) the more "traditional" way of doing AOP with tools like AspectJ,
> instrumenting bundle implementations
>
> 2) AOP at the OSGi service level, "intercepting" existing services and
> adding aspects that way
>
> Both have their advantages and disadvantages, but I am a big fan of doing
> it the last way, because it seems more in touch with the OSGi way of doing
> things: not exposing implementations, only sharing services and their
> versioned packages. So using this mechanism, you can intercept existing
> services and basically add a new service on top of it. By specifying
> priorities you can even chain aspects and determine their ordering and best
> of all, this process is completely dynamic: you can add or remove aspects
> because they can be packaged as separate bundles and even when you update
> underlying services, the aspects will just as happily work on top of the
> updated services.
>
> Actually, I have recently been working on adding support for that form of
> aspect orientation to the Dependency Manager so you can easily add aspects
> to existing services (this is still only available in trunk, not in a
> released version).
>
> An example, let's say use Servlets using the whiteboard pattern and want to
> add an aspect that simply counts the number of invocations to each servlet,
> you could set that up like this:
>
> /** The Bundle Activator for your aspect bundle. */
> public class Activator extends DependencyActivatorBase {
> public void init(BundleContext bc, DependencyManager dm) throws Exception
> {
> dm.add(createAspectService(Servlet.class, null, 1, ServletAspect.class,
> null));
> }
> }
>
> Basically the code above says: for any Servlet service that appears in the
> registry, create an aspect with a service ranking of 1 that is implemented
> by an instance of ServletAspect (that is instantiated for every service).
>
> /** The aspect implementation. */
> public class ServletAspect implements Servlet {
> volatile Servlet m_servlet;
>
> private long m_counter;
> public void service(ServletRequest req, ServletResponse res) {
> synchronized (this) { m_counter++; }
> m_servlet.service(req, res);
> }
> /* implement the other methods of Servlet... */
> }
>
> And this part implements the aspect. It obviously needs to implement the
> same service, and it gets injected with the real service so you can delegate
> to it once you've added whatever you wanted to do in your aspect (such as
> increment a counter in the example).
>
> That's all there is to it.
>
> Greetings, Marcel
>
>
> On Mar 31, 2010, at 8:49 , Ivanhoe Abrahams wrote:
>
> > Hi Teemu
> >
> > Thank you for your reply
> >
> > To be honest, I have not started any experiments yet,
> > No I do not want to instrument the container itself,
> > My immediate experimnent would be to gather some performance
> > metrics/monitoring using AspectJ for my bundles.
> > I think forget about me mentioning dynamic proxies as this is NOT what I
> > want.
> >
> > I was thinking more about problems that others might have encountered in
> > this area, ESPECIALLY classloading restrictions. If any, if there are no
> > real issues in this area the great.
> >
> > In some of the previous messages about this topic there was mention about
> > possibly implementing something similar to the "Equinox-specific hooks to
> > perform load-time weaving" as this was probably also needed for JPA
> hooks.
> > Any informatioon about this would be helpful.
> >
> > Once again, I have not started any experimentation yet.
> > My question is more centered around how to go about this. What are
> other's
> > experience with AOP and OSGI.
> >
> > I am not sure how to start. I am dithering a bit.
> > Ivanhoe
> >
> >
> > On Tue, Mar 30, 2010 at 1:33 PM, teemu kanstren <tk...@gmail.com>
> wrote:
> >
> >> Hello,
> >>
> >> What do you expect to be the difference? What are the results of your
> >> experiments in this regard? Are you instrumenting the container or a set
> of
> >> bundles? You talk about possibility of using a Proxy, what do you plan
> to
> >> use it for?
> >>
> >> I guess some things can depend on your instrumentation code. My guess is
> >> that you could have some classloader issues with multiple bundles
> sharing
> >> some global aspects if you want something like that. But depends on what
> >> you
> >> want to do and also trying it out will tell you the best..
> >>
> >> Teemu
> >>
> >>
> >> 2010/3/30 Ivanhoe Abrahams <iv...@gmail.com>
> >>
> >>> Hi all
> >>>
> >>> I am looking around for the "correct" way for using AOP in OSGI.
> >>> I dont have concrete examples right yet, but basically I would
> eventually
> >>> want to use either Load time weaving OR dynamic proxies,
> >>> preferably with AspectJ, but I dont mind using other AOP frameworks....
> >>> However I do want to use it in a way that is "standard", in other words
> >> it
> >>> should work in at least Felix and Equinox and others if possible.
> >>>
> >>> I see there is already a a thread discussing AOP and Felix but it does
> >> not
> >>> seem to give any answers.
> >>> Google also does not provide any goodness on this topic. At lest not
> that
> >> I
> >>> have found.
> >>>
> >>> So what would be the correct way to implement AOP in OSGI based an
> >> system?
> >>>
> >>> Thank you in advance
> >>> Ivanhoe
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: AOP in Apache Felix
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Ivanhoe,
How to best do AOP in an OSGi environment in general is an interesting question. I think there's two roads you can take here:
1) the more "traditional" way of doing AOP with tools like AspectJ, instrumenting bundle implementations
2) AOP at the OSGi service level, "intercepting" existing services and adding aspects that way
Both have their advantages and disadvantages, but I am a big fan of doing it the last way, because it seems more in touch with the OSGi way of doing things: not exposing implementations, only sharing services and their versioned packages. So using this mechanism, you can intercept existing services and basically add a new service on top of it. By specifying priorities you can even chain aspects and determine their ordering and best of all, this process is completely dynamic: you can add or remove aspects because they can be packaged as separate bundles and even when you update underlying services, the aspects will just as happily work on top of the updated services.
Actually, I have recently been working on adding support for that form of aspect orientation to the Dependency Manager so you can easily add aspects to existing services (this is still only available in trunk, not in a released version).
An example, let's say use Servlets using the whiteboard pattern and want to add an aspect that simply counts the number of invocations to each servlet, you could set that up like this:
/** The Bundle Activator for your aspect bundle. */
public class Activator extends DependencyActivatorBase {
public void init(BundleContext bc, DependencyManager dm) throws Exception {
dm.add(createAspectService(Servlet.class, null, 1, ServletAspect.class, null));
}
}
Basically the code above says: for any Servlet service that appears in the registry, create an aspect with a service ranking of 1 that is implemented by an instance of ServletAspect (that is instantiated for every service).
/** The aspect implementation. */
public class ServletAspect implements Servlet {
volatile Servlet m_servlet;
private long m_counter;
public void service(ServletRequest req, ServletResponse res) {
synchronized (this) { m_counter++; }
m_servlet.service(req, res);
}
/* implement the other methods of Servlet... */
}
And this part implements the aspect. It obviously needs to implement the same service, and it gets injected with the real service so you can delegate to it once you've added whatever you wanted to do in your aspect (such as increment a counter in the example).
That's all there is to it.
Greetings, Marcel
On Mar 31, 2010, at 8:49 , Ivanhoe Abrahams wrote:
> Hi Teemu
>
> Thank you for your reply
>
> To be honest, I have not started any experiments yet,
> No I do not want to instrument the container itself,
> My immediate experimnent would be to gather some performance
> metrics/monitoring using AspectJ for my bundles.
> I think forget about me mentioning dynamic proxies as this is NOT what I
> want.
>
> I was thinking more about problems that others might have encountered in
> this area, ESPECIALLY classloading restrictions. If any, if there are no
> real issues in this area the great.
>
> In some of the previous messages about this topic there was mention about
> possibly implementing something similar to the "Equinox-specific hooks to
> perform load-time weaving" as this was probably also needed for JPA hooks.
> Any informatioon about this would be helpful.
>
> Once again, I have not started any experimentation yet.
> My question is more centered around how to go about this. What are other's
> experience with AOP and OSGI.
>
> I am not sure how to start. I am dithering a bit.
> Ivanhoe
>
>
> On Tue, Mar 30, 2010 at 1:33 PM, teemu kanstren <tk...@gmail.com> wrote:
>
>> Hello,
>>
>> What do you expect to be the difference? What are the results of your
>> experiments in this regard? Are you instrumenting the container or a set of
>> bundles? You talk about possibility of using a Proxy, what do you plan to
>> use it for?
>>
>> I guess some things can depend on your instrumentation code. My guess is
>> that you could have some classloader issues with multiple bundles sharing
>> some global aspects if you want something like that. But depends on what
>> you
>> want to do and also trying it out will tell you the best..
>>
>> Teemu
>>
>>
>> 2010/3/30 Ivanhoe Abrahams <iv...@gmail.com>
>>
>>> Hi all
>>>
>>> I am looking around for the "correct" way for using AOP in OSGI.
>>> I dont have concrete examples right yet, but basically I would eventually
>>> want to use either Load time weaving OR dynamic proxies,
>>> preferably with AspectJ, but I dont mind using other AOP frameworks....
>>> However I do want to use it in a way that is "standard", in other words
>> it
>>> should work in at least Felix and Equinox and others if possible.
>>>
>>> I see there is already a a thread discussing AOP and Felix but it does
>> not
>>> seem to give any answers.
>>> Google also does not provide any goodness on this topic. At lest not that
>> I
>>> have found.
>>>
>>> So what would be the correct way to implement AOP in OSGI based an
>> system?
>>>
>>> Thank you in advance
>>> Ivanhoe
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AOP in Apache Felix
Posted by Ivanhoe Abrahams <iv...@gmail.com>.
Hi Teemu
Thank you for your reply
To be honest, I have not started any experiments yet,
No I do not want to instrument the container itself,
My immediate experimnent would be to gather some performance
metrics/monitoring using AspectJ for my bundles.
I think forget about me mentioning dynamic proxies as this is NOT what I
want.
I was thinking more about problems that others might have encountered in
this area, ESPECIALLY classloading restrictions. If any, if there are no
real issues in this area the great.
In some of the previous messages about this topic there was mention about
possibly implementing something similar to the "Equinox-specific hooks to
perform load-time weaving" as this was probably also needed for JPA hooks.
Any informatioon about this would be helpful.
Once again, I have not started any experimentation yet.
My question is more centered around how to go about this. What are other's
experience with AOP and OSGI.
I am not sure how to start. I am dithering a bit.
Ivanhoe
On Tue, Mar 30, 2010 at 1:33 PM, teemu kanstren <tk...@gmail.com> wrote:
> Hello,
>
> What do you expect to be the difference? What are the results of your
> experiments in this regard? Are you instrumenting the container or a set of
> bundles? You talk about possibility of using a Proxy, what do you plan to
> use it for?
>
> I guess some things can depend on your instrumentation code. My guess is
> that you could have some classloader issues with multiple bundles sharing
> some global aspects if you want something like that. But depends on what
> you
> want to do and also trying it out will tell you the best..
>
> Teemu
>
>
> 2010/3/30 Ivanhoe Abrahams <iv...@gmail.com>
>
> > Hi all
> >
> > I am looking around for the "correct" way for using AOP in OSGI.
> > I dont have concrete examples right yet, but basically I would eventually
> > want to use either Load time weaving OR dynamic proxies,
> > preferably with AspectJ, but I dont mind using other AOP frameworks....
> > However I do want to use it in a way that is "standard", in other words
> it
> > should work in at least Felix and Equinox and others if possible.
> >
> > I see there is already a a thread discussing AOP and Felix but it does
> not
> > seem to give any answers.
> > Google also does not provide any goodness on this topic. At lest not that
> I
> > have found.
> >
> > So what would be the correct way to implement AOP in OSGI based an
> system?
> >
> > Thank you in advance
> > Ivanhoe
> >
>
Re: AOP in Apache Felix
Posted by teemu kanstren <tk...@gmail.com>.
Hello,
What do you expect to be the difference? What are the results of your
experiments in this regard? Are you instrumenting the container or a set of
bundles? You talk about possibility of using a Proxy, what do you plan to
use it for?
I guess some things can depend on your instrumentation code. My guess is
that you could have some classloader issues with multiple bundles sharing
some global aspects if you want something like that. But depends on what you
want to do and also trying it out will tell you the best..
Teemu
2010/3/30 Ivanhoe Abrahams <iv...@gmail.com>
> Hi all
>
> I am looking around for the "correct" way for using AOP in OSGI.
> I dont have concrete examples right yet, but basically I would eventually
> want to use either Load time weaving OR dynamic proxies,
> preferably with AspectJ, but I dont mind using other AOP frameworks....
> However I do want to use it in a way that is "standard", in other words it
> should work in at least Felix and Equinox and others if possible.
>
> I see there is already a a thread discussing AOP and Felix but it does not
> seem to give any answers.
> Google also does not provide any goodness on this topic. At lest not that I
> have found.
>
> So what would be the correct way to implement AOP in OSGI based an system?
>
> Thank you in advance
> Ivanhoe
>