[
https://issues.apache.org/jira/browse/FELIX-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848278#comment-13848278
]
Pierre De Rop commented on FELIX-4352:
--------------------------------------
Hello Jago,
Thanks for the patch.
I committed my initial shell improvements (see FELIX-4294), then I merged your
wtf command and committed it in the revision 1550897.
Now, I have some comments: I believe that the getRoot method should take into
account the service properties of the dependencies.
For instance, consider the following example:
A -> S(name="s1) -> S(name="s2") -> B
and if B is missing, like in the following sample code (using dependency
manager annotations):
{code}
package test;
import org.apache.felix.dm.annotation.api.Component;
import org.apache.felix.dm.annotation.api.Property;
import org.apache.felix.dm.annotation.api.ServiceDependency;
public class Test2 {
public interface S {
}
@Component
public static class A {
@ServiceDependency(filter="(name=s1)")
S _s;
}
@Component
public static class S1 implements S {
@ServiceDependency(filter="(name=s2)")
S _s2;
}
@Component(properties={@Property(name="name", value="s2")})
public static class S2 implements S {
@ServiceDependency
B _missing;
}
public static class B {
}
}
{code}
then the wtf command displays the following:
{code}
The following service(s) are missing:
* test.Test2$B is not found in the service registry
* test.Test2$S (name=s1) is not found in the service registry
* test.Test2$S (name=s2) is not found in the service registry
{code}
I think that what is expected to be displayed in only the "test.Test2$B", which
is the root cause.
I think that we could have a stack overflow if we don't check service
properties.
Also, perhaps a loop detection should also be performed. For instance, if we
have A -> B -> C -> A, then we could also have a potential stack overflow (am I
correct ?).
FYI, I have added some convenient methods in the ComponentDeclaration like
"getServiceProperties", but perhaps we should also add some methods in the
ComponentDependencyDeclaration interface, in order to easily retrieve
dependency filters ?
/Pierre
> Extend shell command to give better insight in where the problem is
> -------------------------------------------------------------------
>
> Key: FELIX-4352
> URL: https://issues.apache.org/jira/browse/FELIX-4352
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
> Affects Versions: dependencymanager.shell-2.0.1
> Reporter: Jago de Vreede
> Assignee: Pierre De Rop
> Attachments: shell wtf 1.3.patch, shell wtf 1.5.patch
>
>
> 'dm notavail' is a command that we use regularly but it can become hard to
> figure out where the actual problem is.
> This patch allows you to find the root cause very quickly example output:
> 60 missing dependencies found.
> -------------------------------------
> Please note that the following bundles are in the RESOLVED state:
> * [65] com.example.mongo
> The following service(s) are missing:
> * com.example.mongo.MongoService is not found in the service registry
> So the shell command tells you that you have a resolved bundle that could
> trigger you where the problem might be. The command can also tell you if a
> configuration is missing as a root cause.
> The shell can be executed by dm wtf
> wtf stands for Where is The Failure
> This issue has 2 patches:
> 'shell wtf 1.3.patch' and contains a patch that works for java 1.3 and the
> current shell.
> 'shell wtf 1.5.patch' and lifts the shell project to java 1.5 (as I
> understand this is something you have planned) and contains java 1.5 code and
> unittests backed by mockito to mock certain stuff.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
