Hi David, I've just created ARIES-353. It covers initial changes to be applied to to the SPI-Fly project structure. These changes transform SPI-Fly into a multi-module project. Once these changes are in SVN, I'll start contributing itests and other improvements.
Thanks, Bartek 2010/6/29 David Bosschaert <[email protected]>: > 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 >
