Community
Participate
Working Groups
Admittedly this is not so much a bug as something JSP would very much appreciate some sort of assistance with. Now that Bug 308402 is fixed when loading an existing Eclipse workspace the index files specified by our SearchParticipant are now loaded by the JDT index. These index files are of the Java translations of JSP files. The problem is these translations never exist on disk, we simply create in memory CompilcationUnits representing the Java translations of the JSP documents and add those to the JDT index through our SearchParticipant. The problem is after closing the workspace these in memory CUs no longer exist. Then when the workspace is opened again JDT finds our index files and then checks to see if the files that were indexed there still exist, they don't because they never really existed they were only ever in memory. Is there any way to prevent this, short of changing the way we do things and actually save our JSP Java translations to disk so that the JDT index doesn't think they have disappeared? More discussion on this can be found starting in Bug 308402 comment 32 and continuing to Bug 308402 comment 34
Satyam, please investigate, Thanks.
I am probably mistaken in my last analysis. The index states is not updated properly and hence next time a file is getting scheduled, the index manager tries to reindex and hence things seem to go bad.
Created attachment 177432 [details] Patch to test Ian, Can you please see if this patch helps?
(In reply to comment #3) > Created an attachment (id=177432) [details] > Patch to test > > Ian, Can you please see if this patch helps? Unfortunately this patch does not seem to make any difference. After opening the workspace again our index file contains the information about the JSP but then as soon as I invoke a search the index file gets emptied of any information about the JSP translation. Any other ideas?
Can you please give me a sample dynamic web project so that I can reproduce the problem easily?
Created attachment 177941 [details] SSE/JSP Patch needed to reproduce the problem (In reply to comment #5) > Can you please give me a sample dynamic web project so that I can reproduce the > problem easily? Unfortunately I need to give you more then just a project to be able to reproduce this. You will need to load a patch into your workspace for our JSP plugins to get our plugins to a state where this is actually reproducible. I am attaching the patch you would need to load up. The plugins from the R3_2_maintenance stream you will need in your workspace to apply the patch are: org.eclipse.jst.jsp.core org.eclipse.jst.jsp.ui org.eclipse.wst.sse.core I will attach a sample project as well.
Created attachment 177942 [details] Sample Project This is a sample project you can use to reproduce the problem. Steps: 1. import the project 2. do a references search on the "neto" method defined in class "foo.Awesome" 3. One result in the "fooy.jsp" page should be found 4. close the workspace (if you have the JSP file open be sure to close it before closing the workspace), then open it again 5. take a look at "[path_to_workspace]/.metadata\.plugins\org.eclipse.jst.jsp.core\jspsearch", there will be one *.index file in there. If you open it up you can see there is index information in there for the one JSP in the project, close the *.index file 6. perform the search again 7. no results will be found (should have found it in the JSP again) 8. open the *.index file again, you will see its contents have been whipped clean
This is because of the call JavaModelManager.getIndexManager().indexLocations.put() in JSPSearchSupport#computeIndexLocation(). It looks like it works if this call is removed. Can you verify?
(In reply to comment #8) > This is because of the call > JavaModelManager.getIndexManager().indexLocations.put() in > JSPSearchSupport#computeIndexLocation(). It looks like it works if this call is > removed. Can you verify? You rock. That call was in there from the old days when Bug 308402 wasn't fixed and we were trying to work around it, unsuccessfully. Thank you very much working through both this and Bug 308402 with me, it has been much appreciated. Closing this as invalid.
Verified for 3.7M2
