[jira] [Comment Edited] (FELIX-4352) Extend shell command to give better insight in where the problem is

["Pierre De Rop (JIRA)" <ji...@apache.org>]

    [ 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/14/13 8:00 AM:
----------------------------------------------------------------

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


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