geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: Long Path Proposal
Date Sat, 08 Apr 2006 02:21:42 GMT
Dain Sundstrom wrote:
> I'd like to propose the following solution to the windows long path 
> problem.  Before, I go into the proposal I'd like to make sure we have 
> a common understanding of the problem.
> Windows has a limit of 256 characters for a file including the full 
> path and the file name.  In the Geronimo 1.1 branch we moved the 
> unpacked configurations from the config-store/# directory into the 
> repository.  Some of our configurations contain very long internal 
> path, and with the addition of the repository path we have exceeded 
> the windows limit.
> I believe we have two issues to address: the long internal paths of 
> our applications make development of geronimo on windows difficult, 
> and the use of unpacked archives in our repository makes use of the 
> server on windows difficult.
> Geronimo applications long internal paths:
> Aaron is going to look at jaring up the WEB-INF/classes and the 
> compiled jsp pages in our war files.
> David Jencks is going to look at either removing the generated web 
> service classes or putting those classes in a nested jar file.
> Unpacked archives in the repository:
> The solution is to not place unpacked archives in our repository.  I 
> (dain) am going to look at using a class loader that can read from 
> classes and resources from jars nested in jars.  Assuming we can find 
> or write a class loader such a class loader, we will need to assure 
> that Tomcat and Jetty can work from a packed archive.
Also need to ensure/test that a security manager policy file can grant 
permissions for all JARS in a CAR or individual nested JARs using a 
codebase URL in the policy file so users have the same level of control 
they would have had in the config-store (at the same time solving the 
issue with the policy files needing to be changed due to the numbered 
directories in the config-store):
> Of course packed archives won't for users that want to hack jsp pages, 
> and for them I think we need to add support for deploying unpacked 
> archives *inplace*.  This means that we won't copy any files from the 
> unpacked application to the repository.  I also think we need to work 
> out any remaining bugs in the hot-deploy directory as this will be the 
> other common way to deploy applications.
Being able to support inplace deployment would be a bonus for web 
developers as it would speed up their develop/test/debug cycle.  Agree 
we still need hot-deploy.

In the mail thread ( ), 
Paul says he uses softlinking so he can edit his JSPs without having to 
copy files etc.
AFAIK on Windows softlink support has some issues and I don't hear of 
many average users using it ( ), so supporting inplace 
deployment sounds like it would be valuable to windows users.

> What do you think?
Wish I had a Mac... :-)

> -dain

View raw message