felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4847) Allow TemporalServiceDependency to be optional
Date Sun, 19 Apr 2015 16:18:58 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14501993#comment-14501993

Pierre De Rop commented on FELIX-4847:

Sorry Tuomas, last week was a very busy one for me.

So, I took time to look into your issue, but I prefer first to be cautious before starting
to make that change (I will explain why) and I would like to see if we can find together a
compromise or workaround that would resolve your issue.
However, you found a bug regarding the missing createCopy in the TemporalServiceDependencyImpl
class and I will create a separate issue in order to fix it. (thanks for reporting).

So, I have concerns about allowing to make a temporal dependency as optional, because first
a temporal dependency is required by nature: a temporal dependency is exactly the same as
a required dependency except that when you invoke it while the target service dependency is
unavailable, then the invocation is blocked until the target service comes up again, or is
replaced by another lower ranked one, or a  time-out  occurs. 
Also, if we allow optional temporal dependencies, we will then have to implement some specific
checks in the sate machine, especially regarding dependencies applied on class fields, and
we will have to document that. Indeed, an optional dependency defined on a class field is
injected with a null object if the dependency is unavailable, but we will then have to make
a specific patch if the dependency is optional and temporal (no null object to be used, instead
a proxy object is injected).
Also, an optional dependency defined on a callback is not injected immediately, but after
the @Start method: this allows to easily implement the whiteboard pattern: you are first bound
with all required dependencies, then you are started, and then optional dependency callbacks
are then invoked. 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).

Now I have attached to this issue two samples that include some integration tests with annotations
and with the runtime bundle that simply handles all itest components. Can you please take
a look and see if they could help in your case ?
Next, if the examples can't help at all, I would then prefer to help you to implement a "custom"
dependency that you could directly use instead of patching the existing dm4 (I'm talking about
a custom dependency like the one from the samples, in http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/customdep/).

So, let me describe the two tgz that I will attach to this issue: one based on maven/pax-exam,
and another one based on bndtools: These two samples are providing an integration test (FoobarIT)
that is defined using annotations, and the runtime bundle is used to handle the FoobarIT component
(no need to parse the annotations yourself).

1) "dm.test.with.maven.tgz" contains a maven/pax exam based example which provides a Foobar
component that depends on a Configuration PID. And there is a corresponding FoobarIT component
(also annotated with the DM annotations) which creates the configuration in its start method.
Now, the real junit test is located in FoobarTest: it's a basic junit test which registers
in the OSGi registry an "Ensure" object instance. The Ensure class is actually the one we
are using in DM integration tests: it's a simple helper that allows to check if components
are crossing some expected steps in the correct order. So, the FoobarTest first registers
an Ensure object in the registry: this then triggers the activation of the FoobarIT component,
which depends on it. The FoobarIT test is then registering a Configuration from its @Start
method; this then triggers the activation of the Foobar component, which is then injected
in the FoobarIT.bind(Foobar) method. At this point, the FoobarIT.bind method just calls "this.ensure.step(2)"
which will unblock the FoobarTest, and finally the test will end successfully.

Now, the pom.xml is actually using pax exams and is inspired from the Apache Configuration
Admin pom, which also provides some integration tests.

2) "dm.test.with.bndtools.tgz"  is exactly the same example, but using bndtools.

If these two examples are really not applicable in your case, then I would then consider to
help writing a custom dependency (like the "path" dependency in the samples).

let me know.

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