Community
Participate
Working Groups
using the 4/26 I build on M7 stream, I've noticed some code throws an IOOB's exception while indexing a JSP file. The "root cause" may well be on our side (we'll be investigating that, but wanted to call this to your attention, in case it indicates some issue in base code that could be fixed for M7). It did not occur in M6 base code. The excepition is thrown by following method in Index class. public String containerRelativePath(String documentPath) { int jarSeparator = documentPath.indexOf(IJavaSearchScope.JAR_FILE_ENTRY_SEPARATOR); return documentPath.substring((jarSeparator == -1 ? this.containerPath.length() : jarSeparator) + 1); } Looking at this code, its obvious (since +1 always added) that if documentPath length and containerPath length are equal, then an index out of bounds error will be thrown. Even if root cause is on our end, you might want to bullet proof your code and if string are equal length, just use whole string. [Or, it might be the +1 was intended only for jarSperator case? but I don't think so]. Thanks.
The documentPath is prefixed by the containerPath. For them to be equal, that would make the documentPath empty. We do not put documents without names into the index. We will detect this case & throw an IllegalArgumentException.
Thanks, looks like we have the opposite problem, the containerPath and documentPath are equal as below. Obviously the containerPath is whole filename, in our case. Again, all I changed was base code, our code is the same, so ... even if our code is wrong, you might want to make your code more bullet proof. Just a suggestion. We'll continue to look at our code for improvement (and if we get a chance, we'll re-run the JSP Example that comes with base Eclipse ... since originally we were just following that. /org.eclipse.wst.sse.core.internal.encoding.newtests/__2F_org_2E_eclipse_2E_wst_2E_sse_2E_core_2E_internal_2E_encoding_2E_newtests_2F_testfiles_2F_regressionTestFiles_2F_defect224293_2F_testshiftjisXmlSyntax_2E_jsp.java
But the containerPath should be: /org.eclipse.wst.sse.core.internal.encoding.newtests Why is yours the full path?
Not sure, we'll continue to investigate what's changed from M6 versions. But thought it might help (obviously) if I included whole stack of what leads up to the IOOB exception. Our Search participant is involved, but first glance doesn't seem to indicate it does much here (other than deleate to other java search function). Namely, at JSPSearchParticipant.indexDocument, this is the code that's executing: SearchEngine.getDefaultSearchParticipant().indexDocument(document, indexPath); ====== Stack trace leading up to IOOB Index.containerRelativePath(String) line: 82 JavaSearchDocumentDelegate(InternalSearchDocument).getContainerRelativePath() line: 30 JavaSearchDocumentDelegate(InternalSearchDocument).removeAllIndexEntries() line: 38 JavaSearchDocumentDelegate(SearchDocument).removeAllIndexEntries() line: 128 JavaSearchParticipant.indexDocument(SearchDocument, IPath) line: 68 JSPSearchParticipant.indexDocument(SearchDocument, IPath) line: 73 IndexManager.indexDocument(SearchDocument, SearchParticipant, Index, IPath) line: 289 IndexManager$1.execute(IProgressMonitor) line: 599 IndexManager(JobManager).run() line: 369
So what is the document path? And the indexPath? We don't see a bug in our code. If you call: SearchEngine.getDefaultSearchParticipant().indexDocument(document, indexPath); with the document path == indexPath, then the bug is in your code.
Please reopen when you can show the bug is in our code. We have released the changes to throw an IllegalArgumentException when the document path is the same as the container path.
Reopening in light of bug 96424. We may need some clarification on how to handle "in memeory" documents. (That is, if this one is the bug, or if 96424 is the bug, or if we're doing something wrong).
Waiting on fix for bug 96424
David: please let us if the fix for 96424 does not do the trick.
