Re: Another instance of Long path problem on windows
It will not matter for configurations in geronimo distribution. All it will do is give the users some extra breathing space (or motivate to move to linux :) ). ++Vamsi On Tue, Mar 11, 2008 at 11:49 PM, Hernan Cunico <[EMAIL PROTECTED]> wrote: > Users can always rename the extracted directory, no matter how we call it > when zip/tar the different distros. If you use only "/g" you may get some 26 > additional characters, but still not a whole lot. > > Do we know how many characters are we leaving available to users? I mean > not counting the directory, what's the largest dir structure > we are using? > > Cheers! > Hernan > > Vamsavardhana Reddy wrote: > > I tried to deploy a tuscany demo sample war file > > demo-alert-aggregator-webapp.war on my Geronimo 2.1 installation on > > windows. When the install directory is > > c:\geronimo-tomcat6-javaee5-2.1, the application deployment failed with > > the following exception: > > > > |Could not scan module for TLD files: > org.apache.tuscany.sca.tuscany-demos/demo-alert-aggregator-webapp/1.2-incubating-SNAPSHOT/war > Filename too long| > > |org.apache.geronimo.common.DeploymentException: Could not scan module > for TLD files: > org.apache.tuscany.sca.tuscany-demos/demo-alert-aggregator-webapp/1.2-incubating-SNAPSHOT/war > Filename too long| > > |at > org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.scanModule > (JspModuleBuilderExtension.java:297)| > > |at > org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getTldFiles > (JspModuleBuilderExtension.java:238)| > > |at > org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder > (JspModuleBuilderExtension.java:179)| > > |at > org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans( > JspModuleBuilderExtension.java:149)| > > |at > org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans( > TomcatModuleBuilder.java:493)| > > |at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans( > SwitchingModuleBuilder.java:165)| > > |at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration( > EARConfigBuilder.java:647)| > > |at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java > :254)| > > |at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java > :133)| > > |at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)| > > |at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39)| > > |at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25)| > > |at java.lang.reflect.Method.invoke(Method.java:585)| > > |at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke > (ReflectionMethodInvoker.java:34)| > > |at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke( > GBeanOperation.java:124)| > > |at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke( > GBeanInstance.java:867)| > > |at org.apache.geronimo.kernel.basic.BasicKernel.invoke( > BasicKernel.java:239)| > > |at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy > (AbstractDeployCommand.java:116)| > > |at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run( > DistributeCommand.java:61)| > > |at java.lang.Thread.run(Thread.java:595)| > > |Caused by: java.util.zip.ZipException: Filename too long| > > |at java.util.zip.ZipFile.open(Native Method)| > > |at java.util.zip.ZipFile.(ZipFile.java:203)| > > |at java.util.jar.JarFile.(JarFile.java:132)| > > |at java.util.jar.JarFile.(JarFile.java:97)| > > |at > org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.scanModule > (JspModuleBuilderExtension.java:289)| > > |... 19 more| > > | > > > > | > > After I renamed the installation directory to c:\g2.1, the application > > deployed successfully (startup failed with some exceptions... but that > > is a different problem.). In our docs, we recommend users to extract > > the archive to a short directory name on windows (for e.g. c:\g). Even > > that does not seem to be effective in the current case as our > > distributions themselves use a long base directory name. Should we > > recommend the users to further shorten the base directory name by > > renaming after extraction? Or should we shorten the base directory name > > in our distros? > > > > ++Vamsi >
Re: Another instance of Long path problem on windows
Users can always rename the extracted directory, no matter how we call it when zip/tar the different distros. If you use only "/g" you may get some 26 additional characters, but still not a whole lot. Do we know how many characters are we leaving available to users? I mean not counting the directory, what's the largest dir structure we are using? Cheers! Hernan Vamsavardhana Reddy wrote: I tried to deploy a tuscany demo sample war file demo-alert-aggregator-webapp.war on my Geronimo 2.1 installation on windows. When the install directory is c:\geronimo-tomcat6-javaee5-2.1, the application deployment failed with the following exception: |Could not scan module for TLD files: org.apache.tuscany.sca.tuscany-demos/demo-alert-aggregator-webapp/1.2-incubating-SNAPSHOT/war Filename too long| |org.apache.geronimo.common.DeploymentException: Could not scan module for TLD files: org.apache.tuscany.sca.tuscany-demos/demo-alert-aggregator-webapp/1.2-incubating-SNAPSHOT/war Filename too long| |at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.scanModule(JspModuleBuilderExtension.java:297)| |at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getTldFiles(JspModuleBuilderExtension.java:238)| |at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:179)| |at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149)| |at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:493)| |at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)| |at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)| |at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)| |at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)| |at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)| |at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)| |at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)| |at java.lang.reflect.Method.invoke(Method.java:585)| |at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)| |at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)| |at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)| |at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)| |at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)| |at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)| |at java.lang.Thread.run(Thread.java:595)| |Caused by: java.util.zip.ZipException: Filename too long| |at java.util.zip.ZipFile.open(Native Method)| |at java.util.zip.ZipFile.(ZipFile.java:203)| |at java.util.jar.JarFile.(JarFile.java:132)| |at java.util.jar.JarFile.(JarFile.java:97)| |at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.scanModule(JspModuleBuilderExtension.java:289)| |... 19 more| | | After I renamed the installation directory to c:\g2.1, the application deployed successfully (startup failed with some exceptions... but that is a different problem.). In our docs, we recommend users to extract the archive to a short directory name on windows (for e.g. c:\g). Even that does not seem to be effective in the current case as our distributions themselves use a long base directory name. Should we recommend the users to further shorten the base directory name by renaming after extraction? Or should we shorten the base directory name in our distros? ++Vamsi
Re: Long path problem on windows
I haven't had a problem running recently on windows due to the long path name problem (although I did in the past). However, I tend not to use very long names anyway. I know this question is about running and not building ... but I'll take the opportunity to point out one other new bit of news on the building front. I was under the impression that we couldn't exceed something in the realm of 14-15 chars before we started to hit the problem building. However, that was with the M1 build on 1.1.1 (where attempting to use a root of c:\geronimo1.1.1 was hitting the problem). With trunk and the current M2 build I can go longer that that (provided I keep the M2 repo root location fairly short and w/o spaces). I was just able to successfully build with a root of 25 chars and do not yet know what the actual limit is. Joe Vamsavardhana Reddy wrote: I have a quick question. We have seen build failures on windows due to long path problem. Has anyone come across problems at runtime due to long path? Thanks, Vamsi
Re: Long path problem on windows
On 9/11/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: I have a quick question. We have seen build failures on windows due to long path problem. Has anyone come across problems at runtime due to long path? Never heard of any. BTW, that'd be interesting to find out how JVM handles the long paths to load classes. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Long path problem on windows
To reproduce long path error during runtime unzip geronimo-tomcat-j2ee-1.2-SNAPSHOT-bin.zip in assemblies/target directory. Thanks Anita --- Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: > I have a quick question. We have seen build failures on windows due > to long > path problem. Has anyone come across problems at runtime due to long > path? > > Thanks, > Vamsi > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Long path problem on windows
I have a quick question. We have seen build failures on windows due to long path problem. Has anyone come across problems at runtime due to long path? Thanks, Vamsi
