You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Daniel Kulp <dk...@apache.org> on 2013/12/13 21:36:26 UTC
blueprint itest failures...
While writing a test for ARIES-1141, I discovered that the blueprint-itests were pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle” instead of the individual “core”, “cm”, etc… bundles. There are several issues:
1) Since karaf and everything has been updated to using the littler bundles, this means we aren’t testing what people are using
2) We haven’t done a “release” of the big bundle since 1.0.0, but there have been releases of the littler things. This means the littler things haven’t had the itests run with them.
3) I flipped the itests to use the little bundles and now we have couple of test failures.
Running org.apache.aries.blueprint.itests.TestRegistrationListener
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec <<< FAILURE!
Running org.apache.aries.blueprint.itests.BlueprintContainerTest
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec <<< FAILURE!
org.apache.aries.blueprint.itests.ASMMultiBundleTest also fails semi-randomly. That may be the sync vs non-sync startup issues. Need to double check that.
If you have some time, please try taking a look. It looks like we may have broken a bunch of things through the various releases and that obviously concerns me. The BlueprintContainerTest is in testScheduledExecMemoryLeak which kind of scares me.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: blueprint itest failures...
Posted by Daniel Kulp <dk...@apache.org>.
The TestRegistrationListener test is failing because the “serviceRegistered” method is never called. However, the serviceUnregistere method is called twice. The first call has a stack trace of:
at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at org.apache.aries.blueprint.utils.ServiceListener.invokeMethod(ServiceListener.java:97)
at org.apache.aries.blueprint.utils.ServiceListener.unregister(ServiceListener.java:64)
at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:321)
at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:250)
at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:237)
at org.apache.aries.blueprint.container.ServiceRecipe.getClasses(ServiceRecipe.java:376)
at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:184)
at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:703)
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
which I find completely bizarre. It’s within ServiceRecipe.register, but unregister is being called?
Dan
On Dec 13, 2013, at 3:36 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> While writing a test for ARIES-1141, I discovered that the blueprint-itests were pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle” instead of the individual “core”, “cm”, etc… bundles. There are several issues:
>
> 1) Since karaf and everything has been updated to using the littler bundles, this means we aren’t testing what people are using
>
> 2) We haven’t done a “release” of the big bundle since 1.0.0, but there have been releases of the littler things. This means the littler things haven’t had the itests run with them.
>
> 3) I flipped the itests to use the little bundles and now we have couple of test failures.
>
> Running org.apache.aries.blueprint.itests.TestRegistrationListener
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec <<< FAILURE!
> Running org.apache.aries.blueprint.itests.BlueprintContainerTest
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec <<< FAILURE!
>
>
> org.apache.aries.blueprint.itests.ASMMultiBundleTest also fails semi-randomly. That may be the sync vs non-sync startup issues. Need to double check that.
>
>
> If you have some time, please try taking a look. It looks like we may have broken a bunch of things through the various releases and that obviously concerns me. The BlueprintContainerTest is in testScheduledExecMemoryLeak which kind of scares me.
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: blueprint itest failures...
Posted by Holly Cummins <ho...@googlemail.com>.
On 16 Dec 2013, at 22:01, Daniel Kulp <dk...@apache.org> wrote:
>
> On Dec 13, 2013, at 7:48 PM, Holly Cummins <ho...@googlemail.com>
[...]
>> It should be that the main build tests the released versions, so über-1.0 and its back-level constituents. Then the snapshot build tests the latest code, which is uber-snapshot and snapshots of each included bundle - ie, the latest code of everything.
>
> Personally, I don’t think the itests should ever be testing the released versions. That doesn’t make a whole lot of sense. As soon as I add a new test, that would cause the build to break. The purpose of the itests is to make sure the stuff we’re working on doesn’t break anything.
Yeah, I mostly agree. The idea with the main 'release' build is that as soon as something needs the snapshot level of a dependency, it bumps the version in the pom - but it doesn't bump it before then just to get coverage (doing so would actually worsen coverage, as well as messing up the import version ranges in the manifests).
So for itests, as soon as we add a new test, we 'need' the latest version of the thing we're testing. Transitive dependencies probably want to stay at the released level, though, so that we cover more combinations across the two builds.
>> If the snapshot build is actually getting that coverage I think it is, and things are failing anyway with individual bundles, I wonder if we need to run tests with both uber and individual bundles?
>
> Or get rid of the uber bundles. That’s the direction I’d prefer going. I’d certainly prefer not having to do double the amount of release and test work
Certainly that would make things a lot easier and cleaner for us (at the possible of making things harder for users who don't have a nice provisioning system in place).
Holly
>
>
>
>>
>> Holly
>>
>> On 13 Dec 2013, at 20:36, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> While writing a test for ARIES-1141, I discovered that the blueprint-itests were pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle” instead of the individual “core”, “cm”, etc… bundles. There are several issues:
>>>
>>> 1) Since karaf and everything has been updated to using the littler bundles, this means we aren’t testing what people are using
>>>
>>> 2) We haven’t done a “release” of the big bundle since 1.0.0, but there have been releases of the littler things. This means the littler things haven’t had the itests run with them.
>>>
>>> 3) I flipped the itests to use the little bundles and now we have couple of test failures.
>>>
>>> Running org.apache.aries.blueprint.itests.TestRegistrationListener
>>> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec <<< FAILURE!
>>> Running org.apache.aries.blueprint.itests.BlueprintContainerTest
>>> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec <<< FAILURE!
>>>
>>>
>>> org.apache.aries.blueprint.itests.ASMMultiBundleTest also fails semi-randomly. That may be the sync vs non-sync startup issues. Need to double check that.
>>>
>>>
>>> If you have some time, please try taking a look. It looks like we may have broken a bunch of things through the various releases and that obviously concerns me. The BlueprintContainerTest is in testScheduledExecMemoryLeak which kind of scares me.
>>>
>>>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: blueprint itest failures...
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 13, 2013, at 7:48 PM, Holly Cummins <ho...@googlemail.com> wrote:
> Another thing that concerns me about this is that it's exactly the sort of problem which the 'withlatestanapshot' build is supposed to catch. It clearly hasn't caught it, so either it's not working as I hoped, or something about the uber bundle makes things pass even if we're running all the latest code.
I had all kinds of issues trying to get the snapshot versions tested. I think some of them were Maven bugs, but we also cannot move to Maven 3.1 yet due to the version plugin.
> It should be that the main build tests the released versions, so über-1.0 and its back-level constituents. Then the snapshot build tests the latest code, which is uber-snapshot and snapshots of each included bundle - ie, the latest code of everything.
Personally, I don’t think the itests should ever be testing the released versions. That doesn’t make a whole lot of sense. As soon as I add a new test, that would cause the build to break. The purpose of the itests is to make sure the stuff we’re working on doesn’t break anything.
> If the snapshot build is actually getting that coverage I think it is, and things are failing anyway with individual bundles, I wonder if we need to run tests with both uber and individual bundles?
Or get rid of the uber bundles. That’s the direction I’d prefer going. I’d certainly prefer not having to do double the amount of release and test work.
Dan
>
> Holly
>
> On 13 Dec 2013, at 20:36, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> While writing a test for ARIES-1141, I discovered that the blueprint-itests were pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle” instead of the individual “core”, “cm”, etc… bundles. There are several issues:
>>
>> 1) Since karaf and everything has been updated to using the littler bundles, this means we aren’t testing what people are using
>>
>> 2) We haven’t done a “release” of the big bundle since 1.0.0, but there have been releases of the littler things. This means the littler things haven’t had the itests run with them.
>>
>> 3) I flipped the itests to use the little bundles and now we have couple of test failures.
>>
>> Running org.apache.aries.blueprint.itests.TestRegistrationListener
>> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec <<< FAILURE!
>> Running org.apache.aries.blueprint.itests.BlueprintContainerTest
>> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec <<< FAILURE!
>>
>>
>> org.apache.aries.blueprint.itests.ASMMultiBundleTest also fails semi-randomly. That may be the sync vs non-sync startup issues. Need to double check that.
>>
>>
>> If you have some time, please try taking a look. It looks like we may have broken a bunch of things through the various releases and that obviously concerns me. The BlueprintContainerTest is in testScheduledExecMemoryLeak which kind of scares me.
>>
>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: blueprint itest failures...
Posted by Holly Cummins <ho...@googlemail.com>.
Another thing that concerns me about this is that it's exactly the sort of problem which the 'withlatestanapshot' build is supposed to catch. It clearly hasn't caught it, so either it's not working as I hoped, or something about the uber bundle makes things pass even if we're running all the latest code.
It should be that the main build tests the released versions, so über-1.0 and its back-level constituents. Then the snapshot build tests the latest code, which is uber-snapshot and snapshots of each included bundle - ie, the latest code of everything.
If the snapshot build is actually getting that coverage I think it is, and things are failing anyway with individual bundles, I wonder if we need to run tests with both uber and individual bundles?
Holly
On 13 Dec 2013, at 20:36, Daniel Kulp <dk...@apache.org> wrote:
>
> While writing a test for ARIES-1141, I discovered that the blueprint-itests were pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle” instead of the individual “core”, “cm”, etc… bundles. There are several issues:
>
> 1) Since karaf and everything has been updated to using the littler bundles, this means we aren’t testing what people are using
>
> 2) We haven’t done a “release” of the big bundle since 1.0.0, but there have been releases of the littler things. This means the littler things haven’t had the itests run with them.
>
> 3) I flipped the itests to use the little bundles and now we have couple of test failures.
>
> Running org.apache.aries.blueprint.itests.TestRegistrationListener
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec <<< FAILURE!
> Running org.apache.aries.blueprint.itests.BlueprintContainerTest
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec <<< FAILURE!
>
>
> org.apache.aries.blueprint.itests.ASMMultiBundleTest also fails semi-randomly. That may be the sync vs non-sync startup issues. Need to double check that.
>
>
> If you have some time, please try taking a look. It looks like we may have broken a bunch of things through the various releases and that obviously concerns me. The BlueprintContainerTest is in testScheduledExecMemoryLeak which kind of scares me.
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>