[
https://issues.apache.org/jira/browse/FELIX-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-4847:
---------------------------------
Attachment: dm.test.with.bndtools.tgz
Attached second example, based on bndtools.
Just run the "myproject.itest" as "Bnd OSGi test launcher" and you will see the
following output in the console:
WARN - main : Setting up test myproject.itest.tests.FoobarTest
MyServiceImpl.updated: conf={foo=bar, service.pid=foobar.Foobar}
[Ensure 1] step 1 [1 main] myproject.itest.components.FoobarIT.start:36
[Ensure 1] waiting for step 2 [1 main]
myproject.itest.tests.FoobarTest.testCreateMyServiceByConfiguration:21
[Ensure 1] step 2 [13 CM Configuration Updater (Update: pid=foobar.Foobar)]
myproject.itest.components.FoobarIT.bind:42
[Ensure 1] arrived at step 2 [1 main]
myproject.itest.tests.FoobarTest.testCreateMyServiceByConfiguration:21
WARN - main : Tearing down test myproject.itest.tests.FoobarTest
Tests run : 1
Passed : 1
Errors : 0
Failures : 0
> Allow TemporalServiceDependency to be optional
> ----------------------------------------------
>
> Key: FELIX-4847
> URL: https://issues.apache.org/jira/browse/FELIX-4847
> Project: Felix
> Issue Type: Wish
> Components: Dependency Manager
> Affects Versions: dependencymanager-3.2.0
> Reporter: Tuomas Kiviaho
> Attachments: dm.test.with.bndtools.tgz, dm.test.with.maven.tgz
>
>
> I wanted to use temporal service to wait for CM update thread to finish what
> it's doing (because the spec doesn't have a non-parallel version).
> Everything worked fine until JUnit test rule said that the component isn't
> ready yet. I was merely checking that every required dependency was also
> available and to my surprise the temporal service was marked unavailable
> until the CM had completed what it was doing.
> 1) Shouldn't temporal service be always available externally via available
> property and keep track on the actual state only internally? This approach
> might not be backwards compatible.
> 2) Could temporal service be allowed to be marked as optional. This would
> suit my use case, but it feels like a 'golden hammer' approach because it
> alters component's state machine behavior a bit which in turn can be harmful
> for other use cases.
> As a workaround I'd have to differentiate the dependencies somehow from each
> other, but I see that the 4.x has removed the dedicated interface that I was
> thinking of relying upon to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
