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 07:55:16 GMT
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 <david.bosschaert@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 <kowalewski.bartosz@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 <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