Community
Participate
Working Groups
Build Identifier: I20100312-1448 When trying to get a WorkingCopy for Compilation Unit, we are coming across this ResourceException. We will be setting the contents of the Buffer directly and not from some physical resource. Reproducible: Always Steps to Reproduce: For Content assist, when JSP file is translated to java file, WTP tries to get the working copy of Package Fragment's complation unit. But we get Resource Exception as "File Not Found" as their is a check for resource exists. We don't have the translated java file in physical but we will be setting the content of buffer directly.
More details would be welcome. Code snippet and stack trace would definitely help.
Hi Olivier and Jay, We're obtaining our compilation unit via: IPackageFragment#getCompilationUnit(String)#getWorkingCopy(WorkingCopyOwner, IProgressMonitor). We have our own WorkingCopyOwner that extends JDT's WorkingCopyOwner, but overrides #getProblemRequestor. The compilation unit's name is just some String we assemble based on the JSP's path. After getting the ICompilationUnit from the #getWorkingCopy call, we set its Buffer's contents with the translated Java we get from the JSP. In some scenarios (Sarika might be able to provide more information on reproducing them), we end up calling #getWorkingCopy() but get a ResourceException that the Resource doesn't exist. Most of the time, not having a Resource backing it seems to work out just dandy. Occasionally, we'll get this trace: -------------------------------------------------------------------------------- File not found: '/Web/src/__2F_Web_2F_WebContent_2F_jPage_2E_jsp.java' org.eclipse.core.internal.resources.ResourceException: Resource '/Web/src/__2F_Web_2F_WebContent_2F_jPage_2E_jsp.java' does not exist. at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:319) at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:196) at org.eclipse.core.internal.resources.File.getContents(File.java:286) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1163) at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:647) at org.eclipse.jdt.internal.core.CompilationUnit$1.getContents(CompilationUnit.java:221) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9553) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9525) at org.eclipse.jdt.internal.compiler.SourceElementParser.parseCompilationUnit(SourceElementParser.java:908) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:170) at org.eclipse.jdt.internal.core.CompilationUnit.buildStructure(CompilationUnit.java:178) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515) at org.eclipse.jdt.internal.core.BecomeWorkingCopyOperation.executeOperation(BecomeWorkingCopyOperation.java:38) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788) at org.eclipse.jdt.internal.core.CompilationUnit.getWorkingCopy(CompilationUnit.java:983) at org.eclipse.jdt.internal.core.CompilationUnit.getWorkingCopy(CompilationUnit.java:958) at org.eclipse.jst.jsp.core.internal.java.JSPTranslation.createCompilationUnit(JSPTranslation.java:472) at org.eclipse.jst.jsp.core.internal.java.JSPTranslation.getCompilationUnit(JSPTranslation.java:354) at org.eclipse.jst.jsp.core.internal.java.JSPTranslation.setProblemCollectingActive(JSPTranslation.java:542) at org.eclipse.jst.jsp.core.internal.validation.JSPJavaValidator.performValidation(JSPJavaValidator.java:318) at org.eclipse.jst.jsp.core.internal.validation.JSPBatchValidator.performValidation(JSPBatchValidator.java:386) at org.eclipse.jst.jsp.core.internal.validation.JSPBatchValidator.validateFile(JSPBatchValidator.java:443) at org.eclipse.jst.jsp.core.internal.validation.JSPBatchValidator$2.run(JSPBatchValidator.java:513) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4694) at org.eclipse.jst.jsp.core.internal.validation.JSPBatchValidator.validate(JSPBatchValidator.java:525) at org.eclipse.wst.validation.Validator$V2.validate(Validator.java:1120) at org.eclipse.wst.validation.internal.ValManager.validate(ValManager.java:699) at org.eclipse.wst.validation.internal.ValManager$1.visit(ValManager.java:663) at org.eclipse.wst.validation.internal.ValManager.accept(ValManager.java:776) at org.eclipse.wst.validation.internal.ValManager.validate(ValManager.java:667) at org.eclipse.wst.validation.internal.ValBuilderJob$Visitor.visit(ValBuilderJob.java:320) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48) at org.eclipse.wst.validation.internal.ValBuilderJob.deltaBuild(ValBuilderJob.java:210) at org.eclipse.wst.validation.internal.ValBuilderJob.run(ValBuilderJob.java:178) at org.eclipse.wst.validation.internal.ValBuilderJob.runInWorkspace(ValBuilderJob.java:125) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
This looks like some code that has not changed for quite a while. When did you see the problem the first time ? I'd like to know how you are setting the contents of the working copy. I understand that you are using the buffer, but I need more details as you are failing in the code that is supposed to retrieve the contents of the unit on disk only if there is no buffer set for the working copy. In org.eclipse.jdt.internal.core.CompilationUnit.getContents() you are in the code that is run when buffer is null. So for some reason, IBuffer buffer = getBufferManager().getBuffer(this); is returning null for your working copy. Please describe the way you are setting the contents of your working copy. Thanks.
Created attachment 164722 [details] Java code fragment
Did you override the method: org.eclipse.jdt.core.WorkingCopyOwner.createBuffer(ICompilationUnit) in your working copy owner ?
Created attachment 164723 [details] code fragment With the actual method to set the contents of the buffer.
(In reply to comment #5) > Did you override the method: > org.eclipse.jdt.core.WorkingCopyOwner.createBuffer(ICompilationUnit) > in your working copy owner ? No, we do not override the method. Only #getProblemRequestor (and #getString for logging). (In reply to comment #3) > This looks like some code that has not changed for quite a while. > When did you see the problem the first time ? > > I'd like to know how you are setting the contents of the working copy. I > understand that you are using the buffer, but I need more details as you are > failing in the code that is supposed to retrieve the contents of the unit on > disk only if there is no buffer set for the working copy. > In org.eclipse.jdt.internal.core.CompilationUnit.getContents() you are in the > code that is run when buffer is null. > So for some reason, > IBuffer buffer = getBufferManager().getBuffer(this); > is returning null for your working copy. > Please describe the way you are setting the contents of your working copy. > > Thanks. I think this has been happening since before Galileo (the bug we're investigating is filed against Galileo, but I recall seeing it before then). Hopefully the attached code fragment sheds a little light into it.
(In reply to comment #7) > I think this has been happening since before Galileo (the bug we're > investigating is filed against Galileo, but I recall seeing it before then). > Hopefully the attached code fragment sheds a little light into it. Could it be possible to get a workspace all set up that reproduces the problem ? I think you are trying to create a working copy out of an non-existing compilation unit. Could you please try instead: workingCopyOwner.getWorkingCopy(..) See: org.eclipse.jdt.core.WorkingCopyOwner.newWorkingCopy(String, IClasspathEntry[], IProgressMonitor)
(In reply to comment #7) > I think this has been happening since before Galileo (the bug we're > investigating is filed against Galileo, but I recall seeing it before then). > Hopefully the attached code fragment sheds a little light into it. Without being rude, this should be reported as soon as possible. Looking at the other bug report (bug 284427) it looks like this is something that is known since end of last year. Reporting it less than two weeks before M7 is less than optimal. Anyway this being said, let's see if the change recommended in comment 8 will work.
(In reply to comment #9) > (In reply to comment #7) > > I think this has been happening since before Galileo (the bug we're > > investigating is filed against Galileo, but I recall seeing it before then). > > Hopefully the attached code fragment sheds a little light into it. > Without being rude, this should be reported as soon as possible. Looking at the > other bug report (bug 284427) it looks like this is something that is known > since end of last year. > Reporting it less than two weeks before M7 is less than optimal. Anyway this > being said, let's see if the change recommended in comment 8 will work. Thanks for your suggestion. I don't think this came off rude; I understand that this came across late. Unfortunately, we didn't have the resources to investigate deeply until this point. I've tried making the change to: ICompilationUnit cu = getWorkingCopyOwner().newWorkingCopy(getClassname() + ".java", getJavaProject().getResolvedClasspath(true), getProgressMonitor()); setContents(cu); We have a couple stray failing unit tests after this change, and modifying the JSP can sometimes produce a translation where none of the names are resolved. I'll continue to investigate.
I believe this exception is expected since the underlying resource doesn't exist. I sent a patch to Nick that is using a fake IFile to create the compilation unit in the corresponding project. Hopefully this will work. This bug should be closed as INVALID as the code used to create the working copy is expected to fail as reported in case the underlying resource doesn't exist. Jay, correct me if I am wrong.
Closing as INVALID. I sent a patch to Nick that seems to address the problem.
(In reply to comment #11) > I believe this exception is expected since the underlying resource doesn't > exist. > I sent a patch to Nick that is using a fake IFile to create the compilation > unit in the corresponding project. > Hopefully this will work. > This bug should be closed as INVALID as the code used to create the working > copy is expected to fail as reported in case the underlying resource doesn't > exist. > > Jay, correct me if I am wrong. Oops, I thought I responded to this. Didn't notice the submit had failed. And Yes, I am okay with that.
Verified for 3.6M7
Verified.
