IvyDE
  1. IvyDE
  2. IVYDE-133

The decorators can throw a NPE at startup

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.0.beta1
    • Fix Version/s: 2.0.0.final
    • Component/s: None
    • Labels:
      None

      Description

      When launching Eclipse, and if there are some failing resolve job, a NPE can be raised:

      java.lang.NullPointerException
              at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration.setConfStatus(IvyClasspathContainerConfiguration.java:329)
              at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration.getModuleDescriptor(IvyClasspathContainerConfiguration.java:634)
              at org.apache.ivyde.eclipse.cpcontainer.IvyResolveJob.run(IvyResolveJob.java:200)
              at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
      

      This may be due to the way the decorator listeners are accessed.

        Issue Links

          Activity

          Hide
          Nicolas Lalevée added a comment -

          I fixed it by removing the error marker on the classpath container: it will be now set on the parent project

          Show
          Nicolas Lalevée added a comment - I fixed it by removing the error marker on the classpath container: it will be now set on the parent project
          Hide
          Nicolas Lalevée added a comment -

          I have also just found out that it is triggering the resolve process twice at Eclipse startup. Not sure who is the guilty here, but illegally accessing some internal classes of the JDT is probably a good suspect.

          Show
          Nicolas Lalevée added a comment - I have also just found out that it is triggering the resolve process twice at Eclipse startup. Not sure who is the guilty here, but illegally accessing some internal classes of the JDT is probably a good suspect.
          Hide
          Nicolas Lalevée added a comment -

          The more I look into this, the more I see that kind of problem marker is a hack to work around that the JDT API doesn't provide extended management of classpath containers.
          The IvyClasspathContainerDecorator is actually trying to redo what exist for IResource (classpath containers are not IResource): org.eclipse.jdt.ui.ProblemsLabelDecorator.
          I think a more proper solution will be to use the already existing marker management, and then more than trying to put an error marker on the classpath container, the error marker will on the java project containing the problematic classpath container.
          If there is no objection, I will change it.

          Show
          Nicolas Lalevée added a comment - The more I look into this, the more I see that kind of problem marker is a hack to work around that the JDT API doesn't provide extended management of classpath containers. The IvyClasspathContainerDecorator is actually trying to redo what exist for IResource (classpath containers are not IResource): org.eclipse.jdt.ui.ProblemsLabelDecorator. I think a more proper solution will be to use the already existing marker management, and then more than trying to put an error marker on the classpath container, the error marker will on the java project containing the problematic classpath container. If there is no objection, I will change it.
          Hide
          Nicolas Lalevée added a comment -

          Thanks for looking into it Matt. Effectivelly the code is badly assuming an order of loading.
          Althouth your solution will avoid the NPE, but we will loose the notifications. IvyDE should probably buffer the non transmitted status when the decorator is not yet there, and as soon as it has been loaded, fire the pending changes.

          Show
          Nicolas Lalevée added a comment - Thanks for looking into it Matt. Effectivelly the code is badly assuming an order of loading. Althouth your solution will avoid the NPE, but we will loose the notifications. IvyDE should probably buffer the non transmitted status when the decorator is not yet there, and as soon as it has been loaded, fire the pending changes.
          Hide
          Matt Goldspink added a comment - - edited

          I hit this error this morning when starting up Eclipse with 2.0.0.beta1. I don't think the statement: "When launching Eclipse, and if there are some failing resolve job" is correct because the code in the IvyClasspathContainerConfiguration.setConfStatus() method says:

                      if (e != null) {
                          setResolveStatus(new Status(IStatus.ERROR, IvyPlugin.ID, IStatus.ERROR, e
                                  .getMessage(), e.getCause()));
                      } else {
                          setResolveStatus(Status.OK_STATUS); <!--- So it sets the status when its ok
                      }
          

          which shows that this method is called everytime, not just when there is an error. I did a bit of debugging and it looks like the line:

                     IvyPlugin.getDefault().getContainerDecorator().statusChaged(this);
          

          throws the null pointer and its because the call to getContainerDecoractor() is returning null. The reason is because Eclipse hasn't yet initialized that part of the plugin because none of the projects are expanded yet. Is it possible to just add a simple check to change the above line to be:

                     IvyClasspathContainerDecorator decorator = IvyPlugin.getDefault().getContainerDecorator();
                     if (decorator != null) {
                              decorator.statusChaged(this);
                     }
          

          Matt

          Show
          Matt Goldspink added a comment - - edited I hit this error this morning when starting up Eclipse with 2.0.0.beta1. I don't think the statement: "When launching Eclipse, and if there are some failing resolve job" is correct because the code in the IvyClasspathContainerConfiguration.setConfStatus() method says: if (e != null ) { setResolveStatus( new Status(IStatus.ERROR, IvyPlugin.ID, IStatus.ERROR, e .getMessage(), e.getCause())); } else { setResolveStatus(Status.OK_STATUS); <!--- So it sets the status when its ok } which shows that this method is called everytime, not just when there is an error. I did a bit of debugging and it looks like the line: IvyPlugin.getDefault().getContainerDecorator().statusChaged( this ); throws the null pointer and its because the call to getContainerDecoractor() is returning null. The reason is because Eclipse hasn't yet initialized that part of the plugin because none of the projects are expanded yet. Is it possible to just add a simple check to change the above line to be: IvyClasspathContainerDecorator decorator = IvyPlugin.getDefault().getContainerDecorator(); if (decorator != null ) { decorator.statusChaged( this ); } Matt

            People

            • Assignee:
              Nicolas Lalevée
              Reporter:
              Nicolas Lalevée
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development