[
https://issues.apache.org/jira/browse/TAPESTRY-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship closed TAPESTRY-2384.
------------------------------------------
Resolution: Fixed
Fix Version/s: (was: 5.0.11)
5.0.14
Assignee: Howard M. Lewis Ship
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.
> OutOfMemoryError exception if a regular file with no extension exists in a
> known component package
> --------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2384
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2384
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-ioc
> Affects Versions: 5.0
> Reporter: Chris Lewis
> Assignee: Howard M. Lewis Ship
> Fix For: 5.0.14
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
