Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Duplicate
-
5.0.13
-
None
-
None
-
Any
Description
So, SVN has an option to use '_' instead of '.' for its private directories.
I discovered the long and hard way that encountering these directories causes Tapestry to freak out:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
at java.lang.StringBuilder.append(StringBuilder.java:119)
at org.apache.tapestry5.ioc.internal.services.ClassNameLocatorImpl.scanDirStream(ClassNameLocatorImpl.java:210)
at org.apache.tapestry5.ioc.internal.services.ClassNameLocatorImpl.scanURL(ClassNameLocatorImpl.java:114)
at org.apache.tapestry5.ioc.internal.services.ClassNameLocatorImpl.findClassesWithinPath(ClassNameLocatorImpl.java:79)
at org.apache.tapestry5.ioc.internal.services.ClassNameLocatorImpl.locateClassNames(ClassNameLocatorImpl.java:60)
at $ClassNameLocator_11b2ced05d7.locateClassNames($ClassNameLocator_11b2ced05d7.java)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.fillNameToClassNameMap(ComponentClassResolverImpl.java:294)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.rebuild(ComponentClassResolverImpl.java:283)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.performRebuild(ComponentClassResolverImpl.java:202)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.access$100(ComponentClassResolverImpl.java:33)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl$2.run(ComponentClassResolverImpl.java:184)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier$2.invoke(ConcurrentBarrier.java:172)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier$2.invoke(ConcurrentBarrier.java:170)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withWrite(ConcurrentBarrier.java:127)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withWrite(ConcurrentBarrier.java:178)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.rebuild(ComponentClassResolverImpl.java:180)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.locate(ComponentClassResolverImpl.java:499)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.access$300(ComponentClassResolverImpl.java:33)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl$4.invoke(ComponentClassResolverImpl.java:433)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl$4.invoke(ComponentClassResolverImpl.java:431)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:75)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.isPageName(ComponentClassResolverImpl.java:429)
at $ComponentClassResolver_11b2ced05d2.isPageName($ComponentClassResolver_11b2ced05d2.java)
at org.apache.tapestry5.services.TapestryModule$30.initializeApplication(TapestryModule.java:1827)
at $ApplicationInitializer_11b2ced05d3.initializeApplication($ApplicationInitializer_11b2ced05d3.java)
at $ApplicationInitializer_11b2ced05d0.initializeApplication($ApplicationInitializer_11b2ced05d0.java)
at org.apache.tapestry5.services.TapestryModule$13.initializeApplication(TapestryModule.java:959)
at $ServletApplicationInitializer_11b2ced05b6.initializeApplication($ServletApplicationInitializer_11b2ced05b6.java)
at org.apache.tapestry5.TapestryFilter.init(TapestryFilter.java:85)
It will use up all available memory and then crash.
Unfortunately, _svn is actually a valid java package name so I think an actual specific exception will have to be made to ignore these directories.
As I understand it, some developers have this SVN option set because Microsoft IIS has the opposite problem: It will fail when there are directories named .svn but not with _svn