felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tuomas Kiviaho (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-4847) Allow TemporalServiceDependency to be optional
Date Tue, 28 Apr 2015 09:55:05 GMT

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

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

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}}

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

This message was sent by Atlassian JIRA

View raw message