aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: SPI-Fly and provider-configuration file names that are different than the abstract service class
Date Tue, 29 Jun 2010 13:20:26 GMT
Hi Bartek,

On 25 June 2010 22:32, Bartosz Kowalewski <kowalewski.bartosz@gmail.com> 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

Mime
View raw message