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):
http://mail-archives.apache.org/mod_mbox/geronimo-user/200602.mbox/[EMAIL
PROTECTED]
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 (
http://www.mail-archive.com/dev%40geronimo.apache.org/msg20272.html ),
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 (
http://shell-shocked.org/article.php?id=284 ), so supporting inplace
deployment sounds like it would be valuable to windows users.
What do you think?
Wish I had a Mac... :-)
John
-dain
