Mailing-List: contact dev-help@tapestry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tapestry development" <dev@tapestry.apache.org>
Message-ID: <1823720713.1217282911757.JavaMail.jira@brutus>
Date: Mon, 28 Jul 2008 15:08:31 -0700 (PDT)
From: "Howard M. Lewis Ship (JIRA)" <dev@tapestry.apache.org>
To: tapestry-dev@jakarta.apache.org
Subject: [jira] Assigned: (TAPESTRY-2523) T5 fails when svn uses underscores
 instead of periods
In-Reply-To: <1019918170.1216239931705.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/TAPESTRY-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship reassigned TAPESTRY-2523:
----------------------------------------------

    Assignee: Howard M. Lewis Ship

> T5 fails when svn uses underscores instead of periods
> -----------------------------------------------------
>
>                 Key: TAPESTRY-2523
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2523
>             Project: Tapestry
>          Issue Type: Bug
>          Components: Core Components
>    Affects Versions: 5.0.13
>         Environment: Any
>            Reporter: Cherry Development
>            Assignee: Howard M. Lewis Ship
>            Priority: Critical
>
> 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

-- 
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org