1 Reply Latest reply on Feb 4, 2010 12:07 AM by jschellSomeoneStoleMyAlias

    Apache or Javac issue?

      With Apache/Tomcat, I am running a system that uses a .jsp page to explicitly invoke the JspRuntimeLibrary.include function to build another web page. Following the Apache source, it appears to ultimately use javac1.6 to compile the created JAVA code. What I am interested in is the HTML that is created by the compiled class...

      My problem is that I am unable to delete the created .java files (although I can delete the .class files.

      I do not know what process is "holding" onto the file handles, but Ihave the same issue on both my development and production systems. My development system is WindowsXP with Tomcat 5, jdk1.6.0_016 and my production system is on Linux with Tomcat 6, Java 1.6 (I am not sure of the build).

      In the following, the full resulting page is stored as a string in HTMLString
      try {
          myout = new StringWriter();
          out = pageContext.getOut();
          org.apache.jasper.runtime.JspRuntimeLibrary.include(request,response, compileFileName, out, true);    
          out = pageContext.getOut();
          HTMLString = myout.toString();
      catch (Throwable t) {
          // == error processing
          HTMLString = "";
      finally {
      After the processing, I have no need of the original source file or the work files (the xxx_jsp.java and the xxx_jsp.class files) so I want to delete them. I use the following to delete the work files:
      //  the "source" jsp uses the sessionId to guarantee a unique name
      //  insert the lead underscore if sessionId starts with a digit
      String workFileName = compileWorkPath +
      if (!(new File(workFileName+".class").delete()) ||
          !(new File(workFileName+".java").delete()) )
         //  do appropriate error processing...
      For both Tomcat5.5 and Tomcat6, the above successfully deletes the .class files, but not the .java files - with a file sharing exception.

      It appears as if the .java files are still "open" somewhere in the Tomcat/Apache/javac processing. If I try to manually delete the .java file it also fails until I do another compile. Once there is a new .java class in the work directory, then I can delete the prior one.

      NOTE: I suspect that this is not a javac issue since I can not replicate the issue when compiling my pure JAVA classes under Eclipse -- but I don't know where to go from here.