[ 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.maven.tgz Attached first example (maven based). when running "mvn clean install", notice the following logs: Running dm.itest.tests.FoobarTest [Ensure 1] step 1 [13 RMI TCP Connection(1)-139.54.130.12] dm.itest.components.FoobarIT.start:31 [Ensure 1] waiting for step 2 [13 RMI TCP Connection(1)-139.54.130.12] dm.itest.tests.FoobarTest.testSimpleAnnotations:46 [Ensure 1] step 2 [17 CM Configuration Updater (Update: pid=org.foo.bar.pid)] dm.itest.components.FoobarIT.bind:42 [Ensure 1] arrived at step 2 [13 RMI TCP Connection(1)-139.54.130.12] dm.itest.tests.FoobarTest.testSimpleAnnotations:46 > 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.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)