[ 
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)

Reply via email to