Bug 96424 - [search] SearchParticipant sets containerPath to documentPath
Summary: [search] SearchParticipant sets containerPath to documentPath
Status: CLOSED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.1 RC2   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 98045 99242 (view as bug list)
Depends on:
Blocks: 93432
  Show dependency tree
 
Reported: 2005-05-24 10:00 EDT by Phillip Avery CLA
Modified: 2005-06-10 13:03 EDT (History)
3 users (show)

See Also:


Attachments
unit test (10.23 KB, application/octet-stream)
2005-06-01 10:43 EDT, Phillip Avery CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phillip Avery CLA 2005-05-24 10:00:34 EDT
The WTP JSP Editor uses SearchParticipant API.
If a searchDocument path doesn't point to something that exists in the
workspace, the index container path is set to equal the document path.

For the call to:
SearchParticipant#scheduleDocumentIndexing(document, indexLocation)

Our JSPSearchDocument#getPath() points to a compilation unit that doesn't
actually exist in the workspace (only in memory).  This causes:

IPath containerPath = 
   resource == null ? documentPath : resource.getProject().getFullPath();

to set containerPath = to the document path

This in turn causes an IllegalArgumentException in Index as of M7 (because
documentPath == containerPath):

Index#containerRelativePath(documentPath)

If the resource doesn't actually exist in the workspace, can the first segment
of the searchDocumentPath be considered the containerPath?  Or might this
have side effects that I haven't anticipated?
Comment 1 Phillip Avery CLA 2005-05-24 13:23:40 EDT
This causes major loss of function for JSP including search and refactoring, so
I'm raising severity.
Comment 2 Frederic Fusier CLA 2005-05-26 10:20:18 EDT
Unfortunately, it's too late for RC1.
I'll try to do my best for (early) RC2...
Comment 3 Frederic Fusier CLA 2005-05-31 11:06:07 EDT
I get some trouble to get this IAE...
Could you provide a simple test case to help me to verify that my fix I'm
thinking about would really fix your problem?
TIA
Comment 4 Phillip Avery CLA 2005-06-01 10:43:29 EDT
Created attachment 22152 [details]
unit test

You will probably have to change the INDEX_LOCATION field and package to run
this unit test. This should expose the problem (I run as JUnit plugin test w/
-debug -consolelog option)
Comment 5 Frederic Fusier CLA 2005-06-02 04:23:31 EDT
*** Bug 98045 has been marked as a duplicate of this bug. ***
Comment 6 Frederic Fusier CLA 2005-06-02 14:05:48 EDT
I cannot reproduce this exception even with your JUnit test case or installing
JST and create project/exit eclipse/delete project/restart eclipse...:-(
Don't know how to verify this... Can I attach a patch text-file that you can
apply or perhaps send you a new org.eclipse.jdt.core.jar file?
Comment 7 Phillip Avery CLA 2005-06-02 14:34:07 EDT
A patch would be fine for me to test.

Strange that the unit test didn't work though...I thought I wrote it so that JST
wasn't required.
Comment 8 Frederic Fusier CLA 2005-06-03 08:19:13 EDT
My fault. Your test is correct. I just forgot to create INDEX_LOCATION folder on
my box (or change it to point on a existing one).
I now get the exception in console and I have verified that my fix works well :-)
It should be released today and available in tomorrow's nightly build...
Comment 9 Frederic Fusier CLA 2005-06-03 11:41:45 EDT
Fixed and released in HEAD.

Modify way to get resource (using JavaModel.getTarget(...)) to keep documentPath
for external jar files. When object is neither an IResource nor a File (ie.
null), then keep only first segment of document path.

[jdt-core internal]
Changes done in SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath).

No test case added but verify that exception does no longer occur with provide
JUnit test case. If time permit, I'll try to modify this test to put in our
model JUnit tests.
Comment 10 Olivier Thomann CLA 2005-06-06 16:43:13 EDT
Verified using N20050606-0010 + JDT/Core HEAD
Comment 11 Jerome Lanneluc CLA 2005-06-10 07:09:25 EDT
Verified with I20050610-0010
Comment 12 Phillip Avery CLA 2005-06-10 13:03:11 EDT
*** Bug 99242 has been marked as a duplicate of this bug. ***