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] [Comment Edited] (FELIX-4352) Extend shell command to give better insight in where the problem is
Date Sun, 15 Dec 2013 09:33:06 GMT

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

Pierre De Rop edited comment on FELIX-4352 at 12/15/13 9:32 AM:
----------------------------------------------------------------

Hello Jago,

Thanks for the patch.
(I'm reediting and replacing my previous response, which was confusing and lacking of clarity
... I hope you did not already read it :-))

So, I committed my initial shell improvements (see FELIX-4294), then I merged the wtf command
and committed it in the revision 1550897.

Now, I played with the wtf command and it works pretty nicely, however here are a few comments:

- I think that the getRoot method needs to take into account the service dependency filter.
Currently, the getRoot method calls "cdd.getName()" method, which returns the service dependency
interface name, optionally followed by a space and the service dependency filter. So, for
service dependencies, I think that the filter should be parsed and if any, be taken into account
when recursively looking for root dependency failures. Alternatively, I wonder if we should
add a convenient method in ComponentDependencyDeclaration interface, like "getServiceFilter()
" ?

- A loop detection should probably also be performed by the getRoot() method in order to avoid
potential  stack overflow, like for instance, when the command is run to track situations
like the following: A -> B -> C -> A ...

many thanks for the patch.
/Pierre


was (Author: pderop):
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(properties={@Property(name="name", value="s1")})
  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)

Mime
View raw message