You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Bartosz Kowalewski <ko...@gmail.com> on 2010/07/08 23:10:57 UTC
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
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 <da...@gmail.com>:
> Hi Bartek,
>
> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by Bartosz Kowalewski <ko...@gmail.com>.
David,
I've just updated ARIES-373 and attached a new veriosn of the patch.
Thanks,
Bartek
2010/8/5 Bartosz Kowalewski <ko...@gmail.com>:
> Hi David,
>
> No problem. I'll refactor and send it again once I'm back. However,
> this will still be just a sandbox. While these changes were made
> against exisiting SPI-Fly projects, these are only initial
> modifications. As it is stated in ARIES-373, there are some problems
> that need to be resolved before these changes find their way to the
> Aries SVN repo.
>
> Thanks,
> Bartek
>
> 2010/8/5 David Bosschaert <da...@gmail.com>:
>> Hi Bartek,
>>
>> If you're planning to do more work on it I would probably prefer to
>> wait until you've finished the patch.
>>
>> Cheers,
>>
>> David
>>
>> On 5 August 2010 02:53, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>> Hi David,
>>>
>>> Sorry for the late response. I was doing a clean-up in my workspace
>>> before leaving for vacation and I realized that I forgot to contribute
>>> my sandbox that proposes how to use aspects with SPI-Fly. I've just
>>> made a quick clean-up and created a patch. It was a really quick
>>> clean-up :). The code still requires refactoring. If you find any part
>>> of this patch useful, I can create a better one once I'm back from
>>> vacation.
>>>
>>> The patch and some details are here:
>>> https://issues.apache.org/jira/browse/ARIES-373
>>>
>>> Thanks,
>>> Bartek
>>>
>>> 2010/7/19 David Bosschaert <da...@gmail.com>:
>>>> Hi Bartek,
>>>>
>>>> That fixed it.
>>>> I've applied the patch to trunk.
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>>
>>>> On 19 July 2010 15:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>> Hi David,
>>>>>
>>>>> I was surprised seeing this error, so I did some investigation. It
>>>>> turned out that this is caused by a misbehaving Maven plugin - the one
>>>>> that is used to generate the dependencies.properties file which is
>>>>> later used by Pax Exam. This plugin sometimes puts resolved snashot
>>>>> versions (i.e. 0.2-incubating-20100717.020505-16) instead of the base
>>>>> versions (i.e. 0.2-incubating-SNAPSHOT) into the generated file. I'm
>>>>> not sure why it is observable only from time to time, but it's
>>>>> definitely a bug.
>>>>>
>>>>> The plugin that is used there is SMX depends-maven-plugin. I found
>>>>> this SMX revision:
>>>>> http://svn.apache.org/viewvc?view=revision&revision=770436
>>>>> Guillaume has already fixed this issue and the fix is available in the
>>>>> latest version of depends-maven-plugin. The only change that needs to
>>>>> be applied to SPI-Fly project is an upgrade in version of the
>>>>> depends-maven-plugin in the spi-fly-itests pom.xml.
>>>>>
>>>>> <groupId>org.apache.servicemix.tooling</groupId>
>>>>> <artifactId>depends-maven-plugin</artifactId>
>>>>> <version>1.1</version>
>>>>> needs to be changed to:
>>>>> <groupId>org.apache.servicemix.tooling</groupId>
>>>>> <artifactId>depends-maven-plugin</artifactId>
>>>>> <version>1.2</version>
>>>>>
>>>>> Do you want me to send you an updated patch? After this small
>>>>> modification is applied, spi-fly-itests should work fine.
>>>>>
>>>>> One more thing: This is a more general issue. I wanted to make the
>>>>> spi-fly-itests Maven and Pax Exam config look as similar to config in
>>>>> other Aries projects. I copied this configuration from application
>>>>> itests. I've just taken a look at other projects and can see that
>>>>> application, jmx, jpa, transaction, and web itest projects all use
>>>>> org.apache.servicemix.tooling in version 1.1. I'll create a new JIRA
>>>>> and attach a patch that upgrades version to 1.2 later today.
>>>>>
>>>>> Thanks,
>>>>> Bartek
>>>>>
>>>>> 2010/7/19 David Bosschaert <da...@gmail.com>:
>>>>>> Hi Bartek,
>>>>>>
>>>>>> Looks good, however the tests fail for me. It comes down to a
>>>>>> dependency that PaxExam is looking for but can't find exactly in my
>>>>>> .m2 repo [1].
>>>>>> Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
>>>>>> see the following versions:
>>>>>> 0.1-incubating
>>>>>> 0.1-incubating-20100329
>>>>>> 0.2-incubating-SNAPSHOT
>>>>>> Also locally building util didn't help...
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> [1]
>>>>>> -------------------------------------------------------------------------------
>>>>>> Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
>>>>>> -------------------------------------------------------------------------------
>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
>>>>>> sec <<< FAILURE!
>>>>>> testProvidersWithandWithoutSpiHeader
>>>>>> [equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
>>>>>> Time elapsed: 0.75 sec <<< ERROR!
>>>>>> java.lang.RuntimeException: URL
>>>>>> [mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
>>>>>> could not be resolved.
>>>>>> at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
>>>>>> at java.net.URL.openStream(URL.java:1010)
>>>>>> at org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
>>>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
>>>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
>>>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
>>>>>> at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
>>>>>> at org.ops4j.pax.runner.Run.start(Run.java:220)
>>>>>> at org.ops4j.pax.runner.Run.start(Run.java:176)
>>>>>> at org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
>>>>>> at org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
>>>>>> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
>>>>>> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
>>>>>> at org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
>>>>>> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
>>>>>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
>>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
>>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
>>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
>>>>>> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
>>>>>> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
>>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
>>>>>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>>>>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>>>>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
>>>>>> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
>>>>>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
>>>>>>
>>>>>> On 16 July 2010 18:04, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Thanks for applying the patch. Here goes another one... :)
>>>>>>> I've just created ARIES-363. This JIRA introduces an itests
>>>>>>> subproject. It also contains a Pax Exam test that checks if the
>>>>>>> existing SPI-Fly mechanisms work okay.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bartek
>>>>>>>
>>>>>>> 2010/7/16 David Bosschaert <da...@gmail.com>:
>>>>>>>> Hi Bartek,
>>>>>>>>
>>>>>>>> I have applied your changes in ARIES-353.
>>>>>>>>
>>>>>>>> Many thanks,
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>>>>>>>>> Hi Bartosz,
>>>>>>>>>
>>>>>>>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>>>>>>> David,
>>>>>>>>>>
>>>>>>>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>>>>>>>
>>>>>>>>>> I can rename the main SPI-Fly project to something else than
>>>>>>>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>>>>>>>> files if you like :).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Bartek
>>>>>>>>>>
>>>>>>>>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>>>>>>>>> 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 <da...@gmail.com>:
>>>>>>>>>>>> Hi Bartek,
>>>>>>>>>>>>
>>>>>>>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by Bartosz Kowalewski <ko...@gmail.com>.
Hi David,
No problem. I'll refactor and send it again once I'm back. However,
this will still be just a sandbox. While these changes were made
against exisiting SPI-Fly projects, these are only initial
modifications. As it is stated in ARIES-373, there are some problems
that need to be resolved before these changes find their way to the
Aries SVN repo.
Thanks,
Bartek
2010/8/5 David Bosschaert <da...@gmail.com>:
> Hi Bartek,
>
> If you're planning to do more work on it I would probably prefer to
> wait until you've finished the patch.
>
> Cheers,
>
> David
>
> On 5 August 2010 02:53, Bartosz Kowalewski <ko...@gmail.com> wrote:
>> Hi David,
>>
>> Sorry for the late response. I was doing a clean-up in my workspace
>> before leaving for vacation and I realized that I forgot to contribute
>> my sandbox that proposes how to use aspects with SPI-Fly. I've just
>> made a quick clean-up and created a patch. It was a really quick
>> clean-up :). The code still requires refactoring. If you find any part
>> of this patch useful, I can create a better one once I'm back from
>> vacation.
>>
>> The patch and some details are here:
>> https://issues.apache.org/jira/browse/ARIES-373
>>
>> Thanks,
>> Bartek
>>
>> 2010/7/19 David Bosschaert <da...@gmail.com>:
>>> Hi Bartek,
>>>
>>> That fixed it.
>>> I've applied the patch to trunk.
>>>
>>> Best regards,
>>>
>>> David
>>>
>>> On 19 July 2010 15:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>> Hi David,
>>>>
>>>> I was surprised seeing this error, so I did some investigation. It
>>>> turned out that this is caused by a misbehaving Maven plugin - the one
>>>> that is used to generate the dependencies.properties file which is
>>>> later used by Pax Exam. This plugin sometimes puts resolved snashot
>>>> versions (i.e. 0.2-incubating-20100717.020505-16) instead of the base
>>>> versions (i.e. 0.2-incubating-SNAPSHOT) into the generated file. I'm
>>>> not sure why it is observable only from time to time, but it's
>>>> definitely a bug.
>>>>
>>>> The plugin that is used there is SMX depends-maven-plugin. I found
>>>> this SMX revision:
>>>> http://svn.apache.org/viewvc?view=revision&revision=770436
>>>> Guillaume has already fixed this issue and the fix is available in the
>>>> latest version of depends-maven-plugin. The only change that needs to
>>>> be applied to SPI-Fly project is an upgrade in version of the
>>>> depends-maven-plugin in the spi-fly-itests pom.xml.
>>>>
>>>> <groupId>org.apache.servicemix.tooling</groupId>
>>>> <artifactId>depends-maven-plugin</artifactId>
>>>> <version>1.1</version>
>>>> needs to be changed to:
>>>> <groupId>org.apache.servicemix.tooling</groupId>
>>>> <artifactId>depends-maven-plugin</artifactId>
>>>> <version>1.2</version>
>>>>
>>>> Do you want me to send you an updated patch? After this small
>>>> modification is applied, spi-fly-itests should work fine.
>>>>
>>>> One more thing: This is a more general issue. I wanted to make the
>>>> spi-fly-itests Maven and Pax Exam config look as similar to config in
>>>> other Aries projects. I copied this configuration from application
>>>> itests. I've just taken a look at other projects and can see that
>>>> application, jmx, jpa, transaction, and web itest projects all use
>>>> org.apache.servicemix.tooling in version 1.1. I'll create a new JIRA
>>>> and attach a patch that upgrades version to 1.2 later today.
>>>>
>>>> Thanks,
>>>> Bartek
>>>>
>>>> 2010/7/19 David Bosschaert <da...@gmail.com>:
>>>>> Hi Bartek,
>>>>>
>>>>> Looks good, however the tests fail for me. It comes down to a
>>>>> dependency that PaxExam is looking for but can't find exactly in my
>>>>> .m2 repo [1].
>>>>> Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
>>>>> see the following versions:
>>>>> 0.1-incubating
>>>>> 0.1-incubating-20100329
>>>>> 0.2-incubating-SNAPSHOT
>>>>> Also locally building util didn't help...
>>>>>
>>>>> Best regards,
>>>>>
>>>>> David
>>>>>
>>>>> [1]
>>>>> -------------------------------------------------------------------------------
>>>>> Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
>>>>> -------------------------------------------------------------------------------
>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
>>>>> sec <<< FAILURE!
>>>>> testProvidersWithandWithoutSpiHeader
>>>>> [equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
>>>>> Time elapsed: 0.75 sec <<< ERROR!
>>>>> java.lang.RuntimeException: URL
>>>>> [mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
>>>>> could not be resolved.
>>>>> at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
>>>>> at java.net.URL.openStream(URL.java:1010)
>>>>> at org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
>>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
>>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
>>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
>>>>> at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
>>>>> at org.ops4j.pax.runner.Run.start(Run.java:220)
>>>>> at org.ops4j.pax.runner.Run.start(Run.java:176)
>>>>> at org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
>>>>> at org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
>>>>> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
>>>>> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
>>>>> at org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
>>>>> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
>>>>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
>>>>> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
>>>>> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
>>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
>>>>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>>>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>>>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
>>>>> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
>>>>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
>>>>>
>>>>> On 16 July 2010 18:04, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> Thanks for applying the patch. Here goes another one... :)
>>>>>> I've just created ARIES-363. This JIRA introduces an itests
>>>>>> subproject. It also contains a Pax Exam test that checks if the
>>>>>> existing SPI-Fly mechanisms work okay.
>>>>>>
>>>>>> Thanks,
>>>>>> Bartek
>>>>>>
>>>>>> 2010/7/16 David Bosschaert <da...@gmail.com>:
>>>>>>> Hi Bartek,
>>>>>>>
>>>>>>> I have applied your changes in ARIES-353.
>>>>>>>
>>>>>>> Many thanks,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>>>>>>>> Hi Bartosz,
>>>>>>>>
>>>>>>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>>>>>> David,
>>>>>>>>>
>>>>>>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>>>>>>
>>>>>>>>> I can rename the main SPI-Fly project to something else than
>>>>>>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>>>>>>> files if you like :).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Bartek
>>>>>>>>>
>>>>>>>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>>>>>>>> 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 <da...@gmail.com>:
>>>>>>>>>>> Hi Bartek,
>>>>>>>>>>>
>>>>>>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by David Bosschaert <da...@gmail.com>.
Hi Bartek,
If you're planning to do more work on it I would probably prefer to
wait until you've finished the patch.
Cheers,
David
On 5 August 2010 02:53, Bartosz Kowalewski <ko...@gmail.com> wrote:
> Hi David,
>
> Sorry for the late response. I was doing a clean-up in my workspace
> before leaving for vacation and I realized that I forgot to contribute
> my sandbox that proposes how to use aspects with SPI-Fly. I've just
> made a quick clean-up and created a patch. It was a really quick
> clean-up :). The code still requires refactoring. If you find any part
> of this patch useful, I can create a better one once I'm back from
> vacation.
>
> The patch and some details are here:
> https://issues.apache.org/jira/browse/ARIES-373
>
> Thanks,
> Bartek
>
> 2010/7/19 David Bosschaert <da...@gmail.com>:
>> Hi Bartek,
>>
>> That fixed it.
>> I've applied the patch to trunk.
>>
>> Best regards,
>>
>> David
>>
>> On 19 July 2010 15:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>> Hi David,
>>>
>>> I was surprised seeing this error, so I did some investigation. It
>>> turned out that this is caused by a misbehaving Maven plugin - the one
>>> that is used to generate the dependencies.properties file which is
>>> later used by Pax Exam. This plugin sometimes puts resolved snashot
>>> versions (i.e. 0.2-incubating-20100717.020505-16) instead of the base
>>> versions (i.e. 0.2-incubating-SNAPSHOT) into the generated file. I'm
>>> not sure why it is observable only from time to time, but it's
>>> definitely a bug.
>>>
>>> The plugin that is used there is SMX depends-maven-plugin. I found
>>> this SMX revision:
>>> http://svn.apache.org/viewvc?view=revision&revision=770436
>>> Guillaume has already fixed this issue and the fix is available in the
>>> latest version of depends-maven-plugin. The only change that needs to
>>> be applied to SPI-Fly project is an upgrade in version of the
>>> depends-maven-plugin in the spi-fly-itests pom.xml.
>>>
>>> <groupId>org.apache.servicemix.tooling</groupId>
>>> <artifactId>depends-maven-plugin</artifactId>
>>> <version>1.1</version>
>>> needs to be changed to:
>>> <groupId>org.apache.servicemix.tooling</groupId>
>>> <artifactId>depends-maven-plugin</artifactId>
>>> <version>1.2</version>
>>>
>>> Do you want me to send you an updated patch? After this small
>>> modification is applied, spi-fly-itests should work fine.
>>>
>>> One more thing: This is a more general issue. I wanted to make the
>>> spi-fly-itests Maven and Pax Exam config look as similar to config in
>>> other Aries projects. I copied this configuration from application
>>> itests. I've just taken a look at other projects and can see that
>>> application, jmx, jpa, transaction, and web itest projects all use
>>> org.apache.servicemix.tooling in version 1.1. I'll create a new JIRA
>>> and attach a patch that upgrades version to 1.2 later today.
>>>
>>> Thanks,
>>> Bartek
>>>
>>> 2010/7/19 David Bosschaert <da...@gmail.com>:
>>>> Hi Bartek,
>>>>
>>>> Looks good, however the tests fail for me. It comes down to a
>>>> dependency that PaxExam is looking for but can't find exactly in my
>>>> .m2 repo [1].
>>>> Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
>>>> see the following versions:
>>>> 0.1-incubating
>>>> 0.1-incubating-20100329
>>>> 0.2-incubating-SNAPSHOT
>>>> Also locally building util didn't help...
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>>
>>>> [1]
>>>> -------------------------------------------------------------------------------
>>>> Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
>>>> -------------------------------------------------------------------------------
>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
>>>> sec <<< FAILURE!
>>>> testProvidersWithandWithoutSpiHeader
>>>> [equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
>>>> Time elapsed: 0.75 sec <<< ERROR!
>>>> java.lang.RuntimeException: URL
>>>> [mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
>>>> could not be resolved.
>>>> at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
>>>> at java.net.URL.openStream(URL.java:1010)
>>>> at org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
>>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
>>>> at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
>>>> at org.ops4j.pax.runner.Run.start(Run.java:220)
>>>> at org.ops4j.pax.runner.Run.start(Run.java:176)
>>>> at org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
>>>> at org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
>>>> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
>>>> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
>>>> at org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
>>>> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
>>>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
>>>> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
>>>> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
>>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
>>>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
>>>> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
>>>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
>>>>
>>>> On 16 July 2010 18:04, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks for applying the patch. Here goes another one... :)
>>>>> I've just created ARIES-363. This JIRA introduces an itests
>>>>> subproject. It also contains a Pax Exam test that checks if the
>>>>> existing SPI-Fly mechanisms work okay.
>>>>>
>>>>> Thanks,
>>>>> Bartek
>>>>>
>>>>> 2010/7/16 David Bosschaert <da...@gmail.com>:
>>>>>> Hi Bartek,
>>>>>>
>>>>>> I have applied your changes in ARIES-353.
>>>>>>
>>>>>> Many thanks,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>>>>>>> Hi Bartosz,
>>>>>>>
>>>>>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>>>>> David,
>>>>>>>>
>>>>>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>>>>>
>>>>>>>> I can rename the main SPI-Fly project to something else than
>>>>>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>>>>>> files if you like :).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Bartek
>>>>>>>>
>>>>>>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>>>>>>> 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 <da...@gmail.com>:
>>>>>>>>>> Hi Bartek,
>>>>>>>>>>
>>>>>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by Bartosz Kowalewski <ko...@gmail.com>.
Hi David,
Sorry for the late response. I was doing a clean-up in my workspace
before leaving for vacation and I realized that I forgot to contribute
my sandbox that proposes how to use aspects with SPI-Fly. I've just
made a quick clean-up and created a patch. It was a really quick
clean-up :). The code still requires refactoring. If you find any part
of this patch useful, I can create a better one once I'm back from
vacation.
The patch and some details are here:
https://issues.apache.org/jira/browse/ARIES-373
Thanks,
Bartek
2010/7/19 David Bosschaert <da...@gmail.com>:
> Hi Bartek,
>
> That fixed it.
> I've applied the patch to trunk.
>
> Best regards,
>
> David
>
> On 19 July 2010 15:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>> Hi David,
>>
>> I was surprised seeing this error, so I did some investigation. It
>> turned out that this is caused by a misbehaving Maven plugin - the one
>> that is used to generate the dependencies.properties file which is
>> later used by Pax Exam. This plugin sometimes puts resolved snashot
>> versions (i.e. 0.2-incubating-20100717.020505-16) instead of the base
>> versions (i.e. 0.2-incubating-SNAPSHOT) into the generated file. I'm
>> not sure why it is observable only from time to time, but it's
>> definitely a bug.
>>
>> The plugin that is used there is SMX depends-maven-plugin. I found
>> this SMX revision:
>> http://svn.apache.org/viewvc?view=revision&revision=770436
>> Guillaume has already fixed this issue and the fix is available in the
>> latest version of depends-maven-plugin. The only change that needs to
>> be applied to SPI-Fly project is an upgrade in version of the
>> depends-maven-plugin in the spi-fly-itests pom.xml.
>>
>> <groupId>org.apache.servicemix.tooling</groupId>
>> <artifactId>depends-maven-plugin</artifactId>
>> <version>1.1</version>
>> needs to be changed to:
>> <groupId>org.apache.servicemix.tooling</groupId>
>> <artifactId>depends-maven-plugin</artifactId>
>> <version>1.2</version>
>>
>> Do you want me to send you an updated patch? After this small
>> modification is applied, spi-fly-itests should work fine.
>>
>> One more thing: This is a more general issue. I wanted to make the
>> spi-fly-itests Maven and Pax Exam config look as similar to config in
>> other Aries projects. I copied this configuration from application
>> itests. I've just taken a look at other projects and can see that
>> application, jmx, jpa, transaction, and web itest projects all use
>> org.apache.servicemix.tooling in version 1.1. I'll create a new JIRA
>> and attach a patch that upgrades version to 1.2 later today.
>>
>> Thanks,
>> Bartek
>>
>> 2010/7/19 David Bosschaert <da...@gmail.com>:
>>> Hi Bartek,
>>>
>>> Looks good, however the tests fail for me. It comes down to a
>>> dependency that PaxExam is looking for but can't find exactly in my
>>> .m2 repo [1].
>>> Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
>>> see the following versions:
>>> 0.1-incubating
>>> 0.1-incubating-20100329
>>> 0.2-incubating-SNAPSHOT
>>> Also locally building util didn't help...
>>>
>>> Best regards,
>>>
>>> David
>>>
>>> [1]
>>> -------------------------------------------------------------------------------
>>> Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
>>> -------------------------------------------------------------------------------
>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
>>> sec <<< FAILURE!
>>> testProvidersWithandWithoutSpiHeader
>>> [equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
>>> Time elapsed: 0.75 sec <<< ERROR!
>>> java.lang.RuntimeException: URL
>>> [mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
>>> could not be resolved.
>>> at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
>>> at java.net.URL.openStream(URL.java:1010)
>>> at org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
>>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
>>> at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
>>> at org.ops4j.pax.runner.Run.start(Run.java:220)
>>> at org.ops4j.pax.runner.Run.start(Run.java:176)
>>> at org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
>>> at org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
>>> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
>>> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
>>> at org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
>>> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
>>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
>>> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
>>> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
>>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
>>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
>>> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
>>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
>>>
>>> On 16 July 2010 18:04, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>> Hi David,
>>>>
>>>> Thanks for applying the patch. Here goes another one... :)
>>>> I've just created ARIES-363. This JIRA introduces an itests
>>>> subproject. It also contains a Pax Exam test that checks if the
>>>> existing SPI-Fly mechanisms work okay.
>>>>
>>>> Thanks,
>>>> Bartek
>>>>
>>>> 2010/7/16 David Bosschaert <da...@gmail.com>:
>>>>> Hi Bartek,
>>>>>
>>>>> I have applied your changes in ARIES-353.
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> David
>>>>>
>>>>> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>>>>>> Hi Bartosz,
>>>>>>
>>>>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>>>> David,
>>>>>>>
>>>>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>>>>
>>>>>>> I can rename the main SPI-Fly project to something else than
>>>>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>>>>> files if you like :).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bartek
>>>>>>>
>>>>>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>>>>>> 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 <da...@gmail.com>:
>>>>>>>>> Hi Bartek,
>>>>>>>>>
>>>>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by David Bosschaert <da...@gmail.com>.
Hi Bartek,
That fixed it.
I've applied the patch to trunk.
Best regards,
David
On 19 July 2010 15:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
> Hi David,
>
> I was surprised seeing this error, so I did some investigation. It
> turned out that this is caused by a misbehaving Maven plugin - the one
> that is used to generate the dependencies.properties file which is
> later used by Pax Exam. This plugin sometimes puts resolved snashot
> versions (i.e. 0.2-incubating-20100717.020505-16) instead of the base
> versions (i.e. 0.2-incubating-SNAPSHOT) into the generated file. I'm
> not sure why it is observable only from time to time, but it's
> definitely a bug.
>
> The plugin that is used there is SMX depends-maven-plugin. I found
> this SMX revision:
> http://svn.apache.org/viewvc?view=revision&revision=770436
> Guillaume has already fixed this issue and the fix is available in the
> latest version of depends-maven-plugin. The only change that needs to
> be applied to SPI-Fly project is an upgrade in version of the
> depends-maven-plugin in the spi-fly-itests pom.xml.
>
> <groupId>org.apache.servicemix.tooling</groupId>
> <artifactId>depends-maven-plugin</artifactId>
> <version>1.1</version>
> needs to be changed to:
> <groupId>org.apache.servicemix.tooling</groupId>
> <artifactId>depends-maven-plugin</artifactId>
> <version>1.2</version>
>
> Do you want me to send you an updated patch? After this small
> modification is applied, spi-fly-itests should work fine.
>
> One more thing: This is a more general issue. I wanted to make the
> spi-fly-itests Maven and Pax Exam config look as similar to config in
> other Aries projects. I copied this configuration from application
> itests. I've just taken a look at other projects and can see that
> application, jmx, jpa, transaction, and web itest projects all use
> org.apache.servicemix.tooling in version 1.1. I'll create a new JIRA
> and attach a patch that upgrades version to 1.2 later today.
>
> Thanks,
> Bartek
>
> 2010/7/19 David Bosschaert <da...@gmail.com>:
>> Hi Bartek,
>>
>> Looks good, however the tests fail for me. It comes down to a
>> dependency that PaxExam is looking for but can't find exactly in my
>> .m2 repo [1].
>> Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
>> see the following versions:
>> 0.1-incubating
>> 0.1-incubating-20100329
>> 0.2-incubating-SNAPSHOT
>> Also locally building util didn't help...
>>
>> Best regards,
>>
>> David
>>
>> [1]
>> -------------------------------------------------------------------------------
>> Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
>> -------------------------------------------------------------------------------
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
>> sec <<< FAILURE!
>> testProvidersWithandWithoutSpiHeader
>> [equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
>> Time elapsed: 0.75 sec <<< ERROR!
>> java.lang.RuntimeException: URL
>> [mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
>> could not be resolved.
>> at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
>> at java.net.URL.openStream(URL.java:1010)
>> at org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
>> at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
>> at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
>> at org.ops4j.pax.runner.Run.start(Run.java:220)
>> at org.ops4j.pax.runner.Run.start(Run.java:176)
>> at org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
>> at org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
>> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
>> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
>> at org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
>> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
>> at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
>> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
>> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
>> at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
>>
>> On 16 July 2010 18:04, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>> Hi David,
>>>
>>> Thanks for applying the patch. Here goes another one... :)
>>> I've just created ARIES-363. This JIRA introduces an itests
>>> subproject. It also contains a Pax Exam test that checks if the
>>> existing SPI-Fly mechanisms work okay.
>>>
>>> Thanks,
>>> Bartek
>>>
>>> 2010/7/16 David Bosschaert <da...@gmail.com>:
>>>> Hi Bartek,
>>>>
>>>> I have applied your changes in ARIES-353.
>>>>
>>>> Many thanks,
>>>>
>>>> David
>>>>
>>>> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>>>>> Hi Bartosz,
>>>>>
>>>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>>>>
>>>>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>>> David,
>>>>>>
>>>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>>>
>>>>>> I can rename the main SPI-Fly project to something else than
>>>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>>>> files if you like :).
>>>>>>
>>>>>> Thanks,
>>>>>> Bartek
>>>>>>
>>>>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>>>>> 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 <da...@gmail.com>:
>>>>>>>> Hi Bartek,
>>>>>>>>
>>>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by Bartosz Kowalewski <ko...@gmail.com>.
Hi David,
I was surprised seeing this error, so I did some investigation. It
turned out that this is caused by a misbehaving Maven plugin - the one
that is used to generate the dependencies.properties file which is
later used by Pax Exam. This plugin sometimes puts resolved snashot
versions (i.e. 0.2-incubating-20100717.020505-16) instead of the base
versions (i.e. 0.2-incubating-SNAPSHOT) into the generated file. I'm
not sure why it is observable only from time to time, but it's
definitely a bug.
The plugin that is used there is SMX depends-maven-plugin. I found
this SMX revision:
http://svn.apache.org/viewvc?view=revision&revision=770436
Guillaume has already fixed this issue and the fix is available in the
latest version of depends-maven-plugin. The only change that needs to
be applied to SPI-Fly project is an upgrade in version of the
depends-maven-plugin in the spi-fly-itests pom.xml.
<groupId>org.apache.servicemix.tooling</groupId>
<artifactId>depends-maven-plugin</artifactId>
<version>1.1</version>
needs to be changed to:
<groupId>org.apache.servicemix.tooling</groupId>
<artifactId>depends-maven-plugin</artifactId>
<version>1.2</version>
Do you want me to send you an updated patch? After this small
modification is applied, spi-fly-itests should work fine.
One more thing: This is a more general issue. I wanted to make the
spi-fly-itests Maven and Pax Exam config look as similar to config in
other Aries projects. I copied this configuration from application
itests. I've just taken a look at other projects and can see that
application, jmx, jpa, transaction, and web itest projects all use
org.apache.servicemix.tooling in version 1.1. I'll create a new JIRA
and attach a patch that upgrades version to 1.2 later today.
Thanks,
Bartek
2010/7/19 David Bosschaert <da...@gmail.com>:
> Hi Bartek,
>
> Looks good, however the tests fail for me. It comes down to a
> dependency that PaxExam is looking for but can't find exactly in my
> .m2 repo [1].
> Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
> see the following versions:
> 0.1-incubating
> 0.1-incubating-20100329
> 0.2-incubating-SNAPSHOT
> Also locally building util didn't help...
>
> Best regards,
>
> David
>
> [1]
> -------------------------------------------------------------------------------
> Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
> sec <<< FAILURE!
> testProvidersWithandWithoutSpiHeader
> [equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
> Time elapsed: 0.75 sec <<< ERROR!
> java.lang.RuntimeException: URL
> [mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
> could not be resolved.
> at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
> at java.net.URL.openStream(URL.java:1010)
> at org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
> at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
> at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
> at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
> at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
> at org.ops4j.pax.runner.Run.start(Run.java:220)
> at org.ops4j.pax.runner.Run.start(Run.java:176)
> at org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
> at org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
> at org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
> at org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
> at org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
> at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
> at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
>
> On 16 July 2010 18:04, Bartosz Kowalewski <ko...@gmail.com> wrote:
>> Hi David,
>>
>> Thanks for applying the patch. Here goes another one... :)
>> I've just created ARIES-363. This JIRA introduces an itests
>> subproject. It also contains a Pax Exam test that checks if the
>> existing SPI-Fly mechanisms work okay.
>>
>> Thanks,
>> Bartek
>>
>> 2010/7/16 David Bosschaert <da...@gmail.com>:
>>> Hi Bartek,
>>>
>>> I have applied your changes in ARIES-353.
>>>
>>> Many thanks,
>>>
>>> David
>>>
>>> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>>>> Hi Bartosz,
>>>>
>>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>>
>>>> Cheers,
>>>>
>>>> David
>>>>
>>>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>>> David,
>>>>>
>>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>>
>>>>> I can rename the main SPI-Fly project to something else than
>>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>>> files if you like :).
>>>>>
>>>>> Thanks,
>>>>> Bartek
>>>>>
>>>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>>>> 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 <da...@gmail.com>:
>>>>>>> Hi Bartek,
>>>>>>>
>>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by David Bosschaert <da...@gmail.com>.
Hi Bartek,
Looks good, however the tests fail for me. It comes down to a
dependency that PaxExam is looking for but can't find exactly in my
.m2 repo [1].
Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
see the following versions:
0.1-incubating
0.1-incubating-20100329
0.2-incubating-SNAPSHOT
Also locally building util didn't help...
Best regards,
David
[1]
-------------------------------------------------------------------------------
Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
sec <<< FAILURE!
testProvidersWithandWithoutSpiHeader
[equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
Time elapsed: 0.75 sec <<< ERROR!
java.lang.RuntimeException: URL
[mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
could not be resolved.
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
at java.net.URL.openStream(URL.java:1010)
at org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
at org.ops4j.pax.runner.Run.start(Run.java:220)
at org.ops4j.pax.runner.Run.start(Run.java:176)
at org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
at org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
at org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
On 16 July 2010 18:04, Bartosz Kowalewski <ko...@gmail.com> wrote:
> Hi David,
>
> Thanks for applying the patch. Here goes another one... :)
> I've just created ARIES-363. This JIRA introduces an itests
> subproject. It also contains a Pax Exam test that checks if the
> existing SPI-Fly mechanisms work okay.
>
> Thanks,
> Bartek
>
> 2010/7/16 David Bosschaert <da...@gmail.com>:
>> Hi Bartek,
>>
>> I have applied your changes in ARIES-353.
>>
>> Many thanks,
>>
>> David
>>
>> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>>> Hi Bartosz,
>>>
>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>>> David,
>>>>
>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>
>>>> I can rename the main SPI-Fly project to something else than
>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>> files if you like :).
>>>>
>>>> Thanks,
>>>> Bartek
>>>>
>>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>>> 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 <da...@gmail.com>:
>>>>>> Hi Bartek,
>>>>>>
>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by Bartosz Kowalewski <ko...@gmail.com>.
Hi David,
Thanks for applying the patch. Here goes another one... :)
I've just created ARIES-363. This JIRA introduces an itests
subproject. It also contains a Pax Exam test that checks if the
existing SPI-Fly mechanisms work okay.
Thanks,
Bartek
2010/7/16 David Bosschaert <da...@gmail.com>:
> Hi Bartek,
>
> I have applied your changes in ARIES-353.
>
> Many thanks,
>
> David
>
> On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
>> Hi Bartosz,
>>
>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>
>> Cheers,
>>
>> David
>>
>> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>>> David,
>>>
>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>
>>> I can rename the main SPI-Fly project to something else than
>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>> files if you like :).
>>>
>>> Thanks,
>>> Bartek
>>>
>>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>>> 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 <da...@gmail.com>:
>>>>> Hi Bartek,
>>>>>
>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>>
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by David Bosschaert <da...@gmail.com>.
Hi Bartek,
I have applied your changes in ARIES-353.
Many thanks,
David
On 15 July 2010 16:59, David Bosschaert <da...@gmail.com> wrote:
> Hi Bartosz,
>
> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>
> Cheers,
>
> David
>
> On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
>> David,
>>
>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>
>> I can rename the main SPI-Fly project to something else than
>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>> files if you like :).
>>
>> Thanks,
>> Bartek
>>
>> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>>> 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 <da...@gmail.com>:
>>>> Hi Bartek,
>>>>
>>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>>
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by David Bosschaert <da...@gmail.com>.
Hi Bartosz,
No I didn't have time to look at ARIES-353 yet. Will do so soon :)
Cheers,
David
On 14 July 2010 09:17, Bartosz Kowalewski <ko...@gmail.com> wrote:
> David,
>
> Have you had chance to take a look at the changes mentioned in ARIES-353?
>
> I can rename the main SPI-Fly project to something else than
> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
> files if you like :).
>
> Thanks,
> Bartek
>
> 2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
>> 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 <da...@gmail.com>:
>>> Hi Bartek,
>>>
>>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>>
>>
>
Re: SPI-Fly and provider-configuration file names that are different
than the abstract service class
Posted by Bartosz Kowalewski <ko...@gmail.com>.
David,
Have you had chance to take a look at the changes mentioned in ARIES-353?
I can rename the main SPI-Fly project to something else than
spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
files if you like :).
Thanks,
Bartek
2010/7/8 Bartosz Kowalewski <ko...@gmail.com>:
> 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 <da...@gmail.com>:
>> Hi Bartek,
>>
>> On 25 June 2010 22:32, Bartosz Kowalewski <ko...@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
>>
>