[ 
https://issues.apache.org/jira/browse/FELIX-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated FELIX-4847:
----------------------------------
    Attachment: TemporalServiceDependencyImpl.java

Sorry about the late response from my behalf as well,

Here's the 3.x patched version that I forgot to include. I took the essential 
parts of from 4.x like the {{waitForService}} approach and the amount of code 
got reduced quite a bit. 

Thanks for the clarification steps. If I understood them correctly nothing on 
this area has been (behavior-wise) changed between 3.x and 4.x. 

{quote}
So, in your usecase, the optional/temporal dependency defined on a callback 
method would again require another specificity in order to call the dependency 
callback immediately since it seems that you want optional temporal dependency 
to be injected immediately (instead of invoking it after the start callback).
{quote}

I base my approach solely on the fact that 3.x injects field (whether or not 
they are required) right after {{@Init}} so at {{@Start}} I have the proxy at 
my disposal. I non-temporal case the proxy would be instead {{NullObject}}. I 
anticipate that this would be the behavior with 4.x as well.

Basically this the custom dependency approach that you refer to but since I 
really like the annotations, I just renamed it as the original one and used 
{{;-split-package:=merge-first}} feature.

Reason why I'm so stubborn is that I believe still that nothing new has to be 
implemented to the state machine itself. It's just that the 
{{TemporalServiceImpl}} seemed to me not to have been following how the 
{{ServiceDependencyImpl}} had evolved and was unintentionally left with more 
complex implementation than really was needed. When I created a custom service 
by copy/pasting and simplified the design I realized that it could be used as a 
drop-in replacement without breaking the original behavior.

> 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: TemporalServiceDependencyImpl.java, 
> 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)

Reply via email to