[
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 to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
