Comment 1 Roberto Sanchez Herrera 2013-09-06 10:27:56 EDT

I found that these exceptions are logged when the enablement expression of these action providers are evaluated: org.eclipse.jdt.ui.navigator.resources.GoIntoActions and org.eclipse.ui.navigator.resources.GoIntoActions

Specifically, this is the expression that is causing the exceptions to be logged:

<and>
<adapt type="org.eclipse.core.resources.IProject" />
							<test property="org.eclipse.core.resources.open" 
                            	value="true"/>
						</and>

Comment 2 Roberto Sanchez Herrera 2013-09-06 10:32:33 EDT

I found that these exceptions are logged when the enablement expression of these action providers are evaluated: org.eclipse.jdt.ui.navigator.resources.GoIntoActions and org.eclipse.ui.navigator.resources.GoIntoActions

Specifically, this is the expression that is causing the exceptions to be logged:

<and>
    <adapt type="org.eclipse.core.resources.IProject" />
    <test property="org.eclipse.core.resources.open" value="true"/> 
</and>

But the failure in the evaluation of this expression is caused by bug201743.

Before bug201743, the adapter to IProject was never found for objects like GroupEJBProvider (even if they implement IAdaptable and adapt IProject). After bug201743, the adapter is found, and then, when the property is tested, the exception is logged. 

I'm investigating which is the best way to fix this.

Comment 3 Roberto Sanchez Herrera 2013-09-06 12:46:53 EDT

Hi, I moved this bug to JDT UI because I believe this is a possible problem with the action provider org.eclipse.ui.navigator.resources.GoIntoActionProvider in org.eclipse-jdt.ui

Its current enablement expression includes this:

<and>
    <adapt type="org.eclipse.core.resources.IProject" />
    <test property="org.eclipse.core.resources.open"  value="true"/>
</and> 

This causes that if the selection Adapts IProject, but is not an IProject, then the property org.eclipse.core.resources.open is tested against the original object (not the adapted one) and then the exception is logged. 

I believe this could be fixed by changing the expression to this:


<and>
    <adapt type="org.eclipse.core.resources.IProject"/>
    <adapt type="org.eclipse.core.resources.IProject">
       <test property="org.eclipse.core.resources.open"  value="true"/>
    </adapt>
</and> 


In this way, if the selection is adaptable to an IProject, then the property will be tested against an IProject object. 

Ideas?

Comment 4 Dani Megert 2013-09-09 06:28:31 EDT

To me this looks like the adapter you return for IProject is not a real IProject, which would be illegal. I just tried this on a random type and as long as it returns an IProject, there is no exception.

Comment 5 Roberto Sanchez Herrera 2013-09-09 10:13:53 EDT

(In reply to Dani Megert from comment #4)
> To me this looks like the adapter you return for IProject is not a real
> IProject, which would be illegal. I just tried this on a random type and as
> long as it returns an IProject, there is no exception.

Thanks for taking  a look at this. The object returned is an IProject. This is the getApadter(Class) method of GroupEJBProvider for example:


public Object getAdapter(Class adapter) {
    if (IProject.class == adapter){
        return ResourcesPlugin.getWorkspace().getRoot().getProject(getProjectName());
    }
    return null;
}

Which random type did you test with?

Comment 6 Dani Megert 2013-09-09 10:49:35 EDT

(In reply to Roberto Sanchez Herrera from comment #5)

I tried again and can now reproduce the problem  with clean 'master' (not sure what went wrong the first time).

Note that your suggested fix would not work and even if it did, it would be a workaround.

Moving to Platform UI for further debugging. Bug 414912 looks similar which is claimed to be fixed for 4.4 M2.

Comment 7 Dani Megert 2013-09-09 10:50:33 EDT

*** Bug 298285 has been marked as a duplicate of this bug. ***

Comment 8 Paul Webster 2013-09-09 11:00:56 EDT

This one was added in bug 302791 for Helios.

PW

Comment 9 Paul Webster 2013-09-09 11:09:50 EDT

It looks like this is suspect:

<and>
    <adapt type="org.eclipse.core.resources.IProject" />
    <test property="org.eclipse.core.resources.open" value="true"/> 
</and>


The test element is outside the adapt element, so you have no gaurantee of the type of object that is being tested.

PW

Comment 10 Roberto Sanchez Herrera 2013-09-09 11:48:48 EDT

(In reply to Paul Webster from comment #9)
> It looks like this is suspect:
> 
> <and>
>     <adapt type="org.eclipse.core.resources.IProject" />
>     <test property="org.eclipse.core.resources.open" value="true"/> 
> </and>
> 
> 
> The test element is outside the adapt element, so you have no gaurantee of
> the type of object that is being tested.
> 
> PW

Hi Paul, 
So was I in the right way in comment#3, and the test of the property should be inside the adapt element to make sure you are using an IProject for testing the property?

Comment 11 Dani Megert 2013-09-10 04:17:14 EDT

(In reply to Paul Webster from comment #9)
> It looks like this is suspect:
> 
> <and>
>     <adapt type="org.eclipse.core.resources.IProject" />
>     <test property="org.eclipse.core.resources.open" value="true"/> 
> </and>
> 
> 
> The test element is outside the adapt element, so you have no gaurantee of
> the type of object that is being tested.
> 
> PW

I should have looked closer. The Expression Language implements conditional and/or but that does not mean it will use the adapter for the next evaluation.

Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=9fe47a4ae03f3e28b7ced0985e1a160853459044

and also in the Navigator who makes the same contribution:

Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c490fbda2425322c236f96f019be38b60caf42e0

Comment 12 Roberto Sanchez Herrera 2013-09-10 09:59:49 EDT

Thank you Dani and Paul.

Comment 13 Paul Webster 2013-09-17 13:40:02 EDT

In 4.4.0.I20130916-2330

PW

Comment 14 Roberto Sanchez Herrera 2013-10-18 11:26:41 EDT

Thank you again for fixing this in Luna. However, it is possible to backport the fix to Kepler SR2?

Comment 15 Dani Megert 2013-10-21 11:50:31 EDT

(In reply to Roberto Sanchez Herrera from comment #14)
> Thank you again for fixing this in Luna. However, it is possible to backport
> the fix to Kepler SR2?

Done, see bug 419992.

Comment 16 Roberto Sanchez Herrera 2013-10-21 11:53:41 EDT

(In reply to Dani Megert from comment #15)
> (In reply to Roberto Sanchez Herrera from comment #14)
> > Thank you again for fixing this in Luna. However, it is possible to backport
> > the fix to Kepler SR2?
> 
> Done, see bug 419992.

Thank you!

Comment 17 Paul Webster 2013-11-22 14:31:19 EST

*** Bug 418241 has been marked as a duplicate of this bug. ***