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 < [email protected]> 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 <[email protected]> > 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 <[email protected]> > >> > >>> 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: [email protected] > For additional commands, e-mail: [email protected] > >
