aries-dev mailing list archives

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

Mime
View raw message