Tapestry
  1. Tapestry
  2. TAPESTRY-2384

OutOfMemoryError exception if a regular file with no extension exists in a known component package

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0
    • Fix Version/s: 5.0.14
    • Component/s: tapestry-ioc
    • Labels:
      None

      Description

      The issue has to do with a temporary queue used to hold package
      names to be scanned for class files, in
      org.apache.tapestry.ioc.internal.services.ClassNameLocatorImpl. For more
      detail see the original bug report with our findings here:

      http://code.google.com/p/tapestry5-components/issues/detail?id=55

      What it comes down to is this: if you have a file in a components
      package without a file extension (such as MIT-LICENSE), Tapestry will
      fail to start because it will have exhausted it's available memory and
      have thrown a java.lang.OutOfMemoryError exception. It assumes such
      files are directory names, and then tacks on a '/' and pushes it on to
      the queue to be searched. This results in a loop that fills the queue
      with bogus package names until the memory is gone.

      Clearly this is an issue and I wanted to provide a patch, but having
      looked a bit at the code, I'm not sure how one can determine if the
      simple strings represent actual directories (as opposed to files with no
      extensions). A new file object could be created, but doing that for each
      iteration seems like it might be slow, as does querying the queue each
      time to see if that package is already contained.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        ClassNameLocator service now uses regular expressions to determine what looks like a component class and what looks like a sub-folder.

        On occasion, an extensionless file (such as README) will be read as if it is a directory, but the regular expressions should keep that from causing too much disruption.

        The OOME was caused by reading a file with blank lines; these were treated as if they were directories, and the URL would be extended by the blank string and a slash. Thus the URLs being scanned as directories would just keep adding trailing slashes and the queue of directory URLs to scan would keep getting bigger until OOME.

        Show
        Howard M. Lewis Ship added a comment - ClassNameLocator service now uses regular expressions to determine what looks like a component class and what looks like a sub-folder. On occasion, an extensionless file (such as README) will be read as if it is a directory, but the regular expressions should keep that from causing too much disruption. The OOME was caused by reading a file with blank lines; these were treated as if they were directories, and the URL would be extended by the blank string and a slash. Thus the URLs being scanned as directories would just keep adding trailing slashes and the queue of directory URLs to scan would keep getting bigger until OOME.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Chris Lewis
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development