In the pursuit of problem solving (or at least trying to) in my research, I guess I am taking AOP as a strategy to give me what I don't have. Maybe I am becoming too addicted to pointcuts... I have used Aspect Oriented Programming for intercepting method calls to the OSGi framework and for adding my "concerns". These interceptions allowed me to, mainly, add hooks to service registration and retrieval. I think the good thing is that the solution was elegant enough and enabled portability accross different OSGi implementations, since the aspects targeted the API. The bad thing is that it does not rely in a standard mechanism supported by the platform, and it needs an additional building step (i.e. weaving the framework).
After taking a look at the draft OSGi spec 4.2, I've checked the Service Registry Hooks with the hope that my weaved hooks could be replaced by a standard mechanism. They have exactly proposed the hooks I wanted but sadly that alternative solution had been rejected. The hooks they will provide still do not allow me to do what I need. I'll still be doing the AOP trick...
I just can think of more pointcuts to add to my future solutions/attempts in order to have other types of hooks. As I said previously, this approach is useful to avoid changing the source code of a chosen OSGi implementation. There are lots of people in the research area who usually customize an OSGi impl to their needs (I still see recent articles talking about customizations of OSCAR). One disadvantage is that if you touch the source code directly, you're stuck with a given version which makes it difficult to follow the evolution of the chosen impl. (either Equinox, KF or Felix). You would need constant effort for merging/synchronization your branch with the current version. I believe they could avoid that by doing the AOP trick as well. However, sometimes (like while writing this) I am not sure if this a true elegant solution or if I've just found a nice and powerful workaround for adding my hooks to the OSGi core.
