Hi Bartek, On 25 June 2010 22:32, Bartosz Kowalewski <[email protected]> wrote: > Hi David, > > I managed to make Eclipse Aspects/Weaving work inside a Pax Exam test. > I can contribute this simple project with integration tests (of course > after applying some clean-up) if you find it useful. I think that > SPI-Fly requires a change in project structure anyway - it needs a > parent project and a second subproject - spifly-itests.
That would be greatly appreciated! > Some more comments on the SPI-Fly + AOP topic: > 1. My understanding is that there's no single uniform mechanism for > supporting AspectJ load-time weaving that would work in all OSGi > containers. Due to the specifics of the OSGi world, container-specific > mechanism are required. Am I right? For Equinox it's Equinox > Aspects/Weaving and there's no such mechanism for Felix. This seems to > be a really important disadvantage of using LTW in SPI-Fly. Yes - there is currently no general mechanism to support load-time weaving in OSGi but this is something being worked on in the OSGi Alliance so I expect that it will be possible in a standardized way in the future. > 2. The problem with adding aspects to bundles is still unresolved. I'm > not sure if there's a clean solution for adding aspects to consumer > bundles (or bundles that provide the API). Of course some ugly > solutions can be applied (like my original headache causing fragment > based one), but these are more intrusive that we might wish. Yes, this is still an open question. Maybe something for the AspectJ mailing list. I will post there. > 3. I started implementing support for SPI-Consumer and SPI-Provider > headers that contain some data helpful whne running the aspect, i.e. > api name and provider name/version for the Provider header, and some > mechanism to define consumer constraints/hints in the SPI-Consumer > header that would help the aspect that will tweak the thread context > classloader to make decisions about providers. These mechanisms are > similar to the ones that you described in one of your e-mails. > However, I feel that we should first solve #1 and #2 above and only > then it makes sense to continue with the implementation. cool stuff - looking forward to your contributions :) Best regards, David
