You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/04/07 23:21:50 UTC
Long Path Proposal
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.
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.
What do you think?
-dain
Re: Long Path Proposal
Posted by Dain Sundstrom <da...@iq80.com>.
I got that patch working with the jmxdebug web app, and committed the
work. Can you look at applying this to the rest of the web
applications.
-dain
On Apr 13, 2006, at 8:23 AM, Prasad Kashyap wrote:
> When I tried to jar up the classes of the servlet-examples, the app
> did not start. It failed with ClassNotFoundException.
>
> Anyways, here is a small patch to jar up the files under
> WEB-INF/classes and place it under WEB-INF/lib/classes.jar. The files
> under classes dir are then deleted.
>
> This option is triggered by a a maven.war.usesJar flag in the
> project.properties. It would have been ideal to replace the war:webapp
> goal from the maven plugin which is where the WEB-INF/classes dir is
> created in the first place. But since we can't get to it, I am using a
> postGoal on that war:webapp goal.
>
>
> Cheers
> Prasad
>
> On 4/12/06, Dain Sundstrom <da...@iq80.com> wrote:
>> I don't know exactly how we do the auto jar, but I would think that
>> we would put the generated jar at WEB-INF/lib/somename.jar. This
>> would only happen when people install applications into the
>> repository, which I would hope it not the normal case for
>> development, so I'm not sure we need to leave the WEB-INF/classes dir
>> in the class path. Then again, there most likely isn't any harm in
>> doing it.
>>
>> -dain
>>
>> On Apr 12, 2006, at 5:37 AM, Sachin Patel wrote:
>>
>>> Sounds good for me as well. At what level will WEB-INF/classes be
>>> jarred? Just the classes themselves or WEB-INF/classes as well? If
>>> we can leave the segment "WEB-INF/classes" exploded it may be
>>> useful users can still drop in class file updates without un/re-
>>> jaring.
>>>
>>> So...
>>>
>>> WEB-INF/classes/classes.jar would contain org/apache/foo.class
>>> WEB-IN/classes/org/apache/foo.class (user dropped class that takes
>>> precedence of jarred version.
>>>
>>> - sachin
>>>
>>>
>>>
>>> On Apr 11, 2006, at 10:51 PM, David Blevins wrote:
>>>
>>>> On Apr 11, 2006, at 6:42 PM, Dain Sundstrom wrote:
>>>>
>>>>> On Apr 7, 2006, at 2:21 PM, Dain Sundstrom wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Well, after two days of hacking, I have a class loader that
>>>>> supports nested jars. The bad news is the console doesn't run
>>>>> anymore. It appears that pluto will only run if the application
>>>>> is not packed (or not packed in a packed jar). Anyway, my guess
>>>>> is that lots of applications will break if the war files are not
>>>>> available unpacked on the file system. The second big problem I
>>>>> am seeing is my new class loader triples the startup time.
>>>>> Surprisingly, my tests show that the slow startup is not due to
>>>>> unpacking nested jars, but is over all slowness in the class
>>>>> loader. My guess is that the URLClassLoader has some native code
>>>>> and that the emory class loader I am using isn't doing as much
>>>>> indexing as the URLClassLoader. So I think it is time I abandon
>>>>> my class loader work (to the sandbox) and we start working on a
>>>>> Plan B:
>>>>>
>>>>> Plan B:
>>>>>
>>>>> o Leave the applications unpacked in the repository.
>>>>>
>>>>> o We should at least warn users when they deploy an application
>>>>> containing long paths (200+ characters from geronimo home dir)
>>>>> and maybe offer to jar the WEB-INF/classes if it will fix the
>>>>> problem.
>>>>>
>>>>> o Shorten the geronimo application path by packing the WEB-INF/
>>>>> classes
>>>>>
>>>>> o Implement inplace deployment so users can place their
>>>>> application wherever they want on the file system.
>>>>>
>>>>>
>>>>> Comments?
>>>>>
>>>>
>>>> Sounds good to me. I think detecting the problem and clearly and
>>>> loudly warning the user of it is a very nice consideration to the
>>>> user -- will save them time. If we automatically packed their
>>>> classes and notified the user of that as an additional clear and
>>>> loud warning message, I think that would be a feature that sets us
>>>> apart from others.
>>>>
>>>> -David
>>>>
>>
>>
>> <console-standard.patch>
>> <start.log>
Re: Long Path Proposal
Posted by Prasad Kashyap <go...@gmail.com>.
When I tried to jar up the classes of the servlet-examples, the app
did not start. It failed with ClassNotFoundException.
Anyways, here is a small patch to jar up the files under
WEB-INF/classes and place it under WEB-INF/lib/classes.jar. The files
under classes dir are then deleted.
This option is triggered by a a maven.war.usesJar flag in the
project.properties. It would have been ideal to replace the war:webapp
goal from the maven plugin which is where the WEB-INF/classes dir is
created in the first place. But since we can't get to it, I am using a
postGoal on that war:webapp goal.
Cheers
Prasad
On 4/12/06, Dain Sundstrom <da...@iq80.com> wrote:
> I don't know exactly how we do the auto jar, but I would think that
> we would put the generated jar at WEB-INF/lib/somename.jar. This
> would only happen when people install applications into the
> repository, which I would hope it not the normal case for
> development, so I'm not sure we need to leave the WEB-INF/classes dir
> in the class path. Then again, there most likely isn't any harm in
> doing it.
>
> -dain
>
> On Apr 12, 2006, at 5:37 AM, Sachin Patel wrote:
>
> > Sounds good for me as well. At what level will WEB-INF/classes be
> > jarred? Just the classes themselves or WEB-INF/classes as well? If
> > we can leave the segment "WEB-INF/classes" exploded it may be
> > useful users can still drop in class file updates without un/re-
> > jaring.
> >
> > So...
> >
> > WEB-INF/classes/classes.jar would contain org/apache/foo.class
> > WEB-IN/classes/org/apache/foo.class (user dropped class that takes
> > precedence of jarred version.
> >
> > - sachin
> >
> >
> >
> > On Apr 11, 2006, at 10:51 PM, David Blevins wrote:
> >
> >> On Apr 11, 2006, at 6:42 PM, Dain Sundstrom wrote:
> >>
> >>> On Apr 7, 2006, at 2:21 PM, Dain Sundstrom wrote:
> >>>
> >>>> 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.
> >>>
> >>> Well, after two days of hacking, I have a class loader that
> >>> supports nested jars. The bad news is the console doesn't run
> >>> anymore. It appears that pluto will only run if the application
> >>> is not packed (or not packed in a packed jar). Anyway, my guess
> >>> is that lots of applications will break if the war files are not
> >>> available unpacked on the file system. The second big problem I
> >>> am seeing is my new class loader triples the startup time.
> >>> Surprisingly, my tests show that the slow startup is not due to
> >>> unpacking nested jars, but is over all slowness in the class
> >>> loader. My guess is that the URLClassLoader has some native code
> >>> and that the emory class loader I am using isn't doing as much
> >>> indexing as the URLClassLoader. So I think it is time I abandon
> >>> my class loader work (to the sandbox) and we start working on a
> >>> Plan B:
> >>>
> >>> Plan B:
> >>>
> >>> o Leave the applications unpacked in the repository.
> >>>
> >>> o We should at least warn users when they deploy an application
> >>> containing long paths (200+ characters from geronimo home dir)
> >>> and maybe offer to jar the WEB-INF/classes if it will fix the
> >>> problem.
> >>>
> >>> o Shorten the geronimo application path by packing the WEB-INF/
> >>> classes
> >>>
> >>> o Implement inplace deployment so users can place their
> >>> application wherever they want on the file system.
> >>>
> >>>
> >>> Comments?
> >>>
> >>
> >> Sounds good to me. I think detecting the problem and clearly and
> >> loudly warning the user of it is a very nice consideration to the
> >> user -- will save them time. If we automatically packed their
> >> classes and notified the user of that as an additional clear and
> >> loud warning message, I think that would be a feature that sets us
> >> apart from others.
> >>
> >> -David
> >>
>
>
Re: Long Path Proposal
Posted by Dain Sundstrom <da...@iq80.com>.
I don't know exactly how we do the auto jar, but I would think that
we would put the generated jar at WEB-INF/lib/somename.jar. This
would only happen when people install applications into the
repository, which I would hope it not the normal case for
development, so I'm not sure we need to leave the WEB-INF/classes dir
in the class path. Then again, there most likely isn't any harm in
doing it.
-dain
On Apr 12, 2006, at 5:37 AM, Sachin Patel wrote:
> Sounds good for me as well. At what level will WEB-INF/classes be
> jarred? Just the classes themselves or WEB-INF/classes as well? If
> we can leave the segment "WEB-INF/classes" exploded it may be
> useful users can still drop in class file updates without un/re-
> jaring.
>
> So...
>
> WEB-INF/classes/classes.jar would contain org/apache/foo.class
> WEB-IN/classes/org/apache/foo.class (user dropped class that takes
> precedence of jarred version.
>
> - sachin
>
>
>
> On Apr 11, 2006, at 10:51 PM, David Blevins wrote:
>
>> On Apr 11, 2006, at 6:42 PM, Dain Sundstrom wrote:
>>
>>> On Apr 7, 2006, at 2:21 PM, Dain Sundstrom wrote:
>>>
>>>> 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.
>>>
>>> Well, after two days of hacking, I have a class loader that
>>> supports nested jars. The bad news is the console doesn't run
>>> anymore. It appears that pluto will only run if the application
>>> is not packed (or not packed in a packed jar). Anyway, my guess
>>> is that lots of applications will break if the war files are not
>>> available unpacked on the file system. The second big problem I
>>> am seeing is my new class loader triples the startup time.
>>> Surprisingly, my tests show that the slow startup is not due to
>>> unpacking nested jars, but is over all slowness in the class
>>> loader. My guess is that the URLClassLoader has some native code
>>> and that the emory class loader I am using isn't doing as much
>>> indexing as the URLClassLoader. So I think it is time I abandon
>>> my class loader work (to the sandbox) and we start working on a
>>> Plan B:
>>>
>>> Plan B:
>>>
>>> o Leave the applications unpacked in the repository.
>>>
>>> o We should at least warn users when they deploy an application
>>> containing long paths (200+ characters from geronimo home dir)
>>> and maybe offer to jar the WEB-INF/classes if it will fix the
>>> problem.
>>>
>>> o Shorten the geronimo application path by packing the WEB-INF/
>>> classes
>>>
>>> o Implement inplace deployment so users can place their
>>> application wherever they want on the file system.
>>>
>>>
>>> Comments?
>>>
>>
>> Sounds good to me. I think detecting the problem and clearly and
>> loudly warning the user of it is a very nice consideration to the
>> user -- will save them time. If we automatically packed their
>> classes and notified the user of that as an additional clear and
>> loud warning message, I think that would be a feature that sets us
>> apart from others.
>>
>> -David
>>
Re: Long Path Proposal
Posted by Sachin Patel <sp...@gmail.com>.
Sounds good for me as well. At what level will WEB-INF/classes be
jarred? Just the classes themselves or WEB-INF/classes as well? If
we can leave the segment "WEB-INF/classes" exploded it may be useful
users can still drop in class file updates without un/re-jaring.
So...
WEB-INF/classes/classes.jar would contain org/apache/foo.class
WEB-IN/classes/org/apache/foo.class (user dropped class that takes
precedence of jarred version.
- sachin
On Apr 11, 2006, at 10:51 PM, David Blevins wrote:
> On Apr 11, 2006, at 6:42 PM, Dain Sundstrom wrote:
>
>> On Apr 7, 2006, at 2:21 PM, Dain Sundstrom wrote:
>>
>>> 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.
>>
>> Well, after two days of hacking, I have a class loader that
>> supports nested jars. The bad news is the console doesn't run
>> anymore. It appears that pluto will only run if the application
>> is not packed (or not packed in a packed jar). Anyway, my guess
>> is that lots of applications will break if the war files are not
>> available unpacked on the file system. The second big problem I
>> am seeing is my new class loader triples the startup time.
>> Surprisingly, my tests show that the slow startup is not due to
>> unpacking nested jars, but is over all slowness in the class
>> loader. My guess is that the URLClassLoader has some native code
>> and that the emory class loader I am using isn't doing as much
>> indexing as the URLClassLoader. So I think it is time I abandon
>> my class loader work (to the sandbox) and we start working on a
>> Plan B:
>>
>> Plan B:
>>
>> o Leave the applications unpacked in the repository.
>>
>> o We should at least warn users when they deploy an application
>> containing long paths (200+ characters from geronimo home dir) and
>> maybe offer to jar the WEB-INF/classes if it will fix the problem.
>>
>> o Shorten the geronimo application path by packing the WEB-INF/
>> classes
>>
>> o Implement inplace deployment so users can place their
>> application wherever they want on the file system.
>>
>>
>> Comments?
>>
>
> Sounds good to me. I think detecting the problem and clearly and
> loudly warning the user of it is a very nice consideration to the
> user -- will save them time. If we automatically packed their
> classes and notified the user of that as an additional clear and
> loud warning message, I think that would be a feature that sets us
> apart from others.
>
> -David
>
Re: Long Path Proposal
Posted by David Blevins <da...@visi.com>.
On Apr 11, 2006, at 6:42 PM, Dain Sundstrom wrote:
> On Apr 7, 2006, at 2:21 PM, Dain Sundstrom wrote:
>
>> 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.
>
> Well, after two days of hacking, I have a class loader that
> supports nested jars. The bad news is the console doesn't run
> anymore. It appears that pluto will only run if the application is
> not packed (or not packed in a packed jar). Anyway, my guess is
> that lots of applications will break if the war files are not
> available unpacked on the file system. The second big problem I am
> seeing is my new class loader triples the startup time.
> Surprisingly, my tests show that the slow startup is not due to
> unpacking nested jars, but is over all slowness in the class
> loader. My guess is that the URLClassLoader has some native code
> and that the emory class loader I am using isn't doing as much
> indexing as the URLClassLoader. So I think it is time I abandon my
> class loader work (to the sandbox) and we start working on a Plan B:
>
> Plan B:
>
> o Leave the applications unpacked in the repository.
>
> o We should at least warn users when they deploy an application
> containing long paths (200+ characters from geronimo home dir) and
> maybe offer to jar the WEB-INF/classes if it will fix the problem.
>
> o Shorten the geronimo application path by packing the WEB-INF/classes
>
> o Implement inplace deployment so users can place their application
> wherever they want on the file system.
>
>
> Comments?
>
Sounds good to me. I think detecting the problem and clearly and
loudly warning the user of it is a very nice consideration to the
user -- will save them time. If we automatically packed their
classes and notified the user of that as an additional clear and loud
warning message, I think that would be a feature that sets us apart
from others.
-David
Re: Long Path Proposal
Posted by Hernan Cunico <hc...@gmail.com>.
I think we should try to make it *simple* for the final user. Having unpacked the jar creates a mile
long path that makes it unpractical for anybody to follow, this is totally independent on whether it
is supported or not by the OS. We don't need a "paragraph" to describe where a file is, right?
Seeing the Plan B I feel like we are ruling out Windows users by transferring them all these
limitations.
Can you expand on "in place deployment"? If I get it right, my first impression is that there would
not be any direct association (by looking at the FS) between a directory and an application served
by Geronimo. Second we could potentially gain some chars but we could equally loose some depending
how you organize your directories and apps. Who would like to have all the apps hanging right from
the root
Anyway, I keep thinking simpler is better, of course, it is easier to say it than to fix it ;)
Cheers!
Hernan
Dain Sundstrom wrote:
> On Apr 7, 2006, at 2:21 PM, Dain Sundstrom wrote:
>
>> 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.
>
>
> Well, after two days of hacking, I have a class loader that supports
> nested jars. The bad news is the console doesn't run anymore. It
> appears that pluto will only run if the application is not packed (or
> not packed in a packed jar). Anyway, my guess is that lots of
> applications will break if the war files are not available unpacked on
> the file system. The second big problem I am seeing is my new class
> loader triples the startup time. Surprisingly, my tests show that the
> slow startup is not due to unpacking nested jars, but is over all
> slowness in the class loader. My guess is that the URLClassLoader has
> some native code and that the emory class loader I am using isn't doing
> as much indexing as the URLClassLoader. So I think it is time I
> abandon my class loader work (to the sandbox) and we start working on a
> Plan B:
>
> Plan B:
>
> o Leave the applications unpacked in the repository.
>
> o We should at least warn users when they deploy an application
> containing long paths (200+ characters from geronimo home dir) and
> maybe offer to jar the WEB-INF/classes if it will fix the problem.
>
> o Shorten the geronimo application path by packing the WEB-INF/classes
>
> o Implement inplace deployment so users can place their application
> wherever they want on the file system.
>
>
> Comments?
>
> -dain
>
>
>
>
Re: Long Path Proposal
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 7, 2006, at 2:21 PM, Dain Sundstrom wrote:
> 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.
Well, after two days of hacking, I have a class loader that supports
nested jars. The bad news is the console doesn't run anymore. It
appears that pluto will only run if the application is not packed (or
not packed in a packed jar). Anyway, my guess is that lots of
applications will break if the war files are not available unpacked
on the file system. The second big problem I am seeing is my new
class loader triples the startup time. Surprisingly, my tests show
that the slow startup is not due to unpacking nested jars, but is
over all slowness in the class loader. My guess is that the
URLClassLoader has some native code and that the emory class loader I
am using isn't doing as much indexing as the URLClassLoader. So I
think it is time I abandon my class loader work (to the sandbox) and
we start working on a Plan B:
Plan B:
o Leave the applications unpacked in the repository.
o We should at least warn users when they deploy an application
containing long paths (200+ characters from geronimo home dir) and
maybe offer to jar the WEB-INF/classes if it will fix the problem.
o Shorten the geronimo application path by packing the WEB-INF/classes
o Implement inplace deployment so users can place their application
wherever they want on the file system.
Comments?
-dain
Re: Long Path Proposal
Posted by Dain Sundstrom <da...@iq80.com>.
Sorry hit the send button to quick...
The biggest ding against the equinox code is the license. The code
is not apache licensed so I can't for it to Geronimo and I'm not an
equinox committer so I can't get changes in. Even if I did get the
changes in, I'd have to wait for a release anytime we wanted a change
to the class loader. Considering how critical the CL is to Geronimo,
I think we should have the code in our tree.
-dain
On Apr 8, 2006, at 3:01 PM, Dain Sundstrom wrote:
> one-jar only supports one level of nesting
>
> I'm not a fan of the equinox code base. I normally spend forever
> searching for stuff and then the code is very weird since they seem
> to be supporting super old versions of java.
>
> Thanks for the links, but the emory code will be easy to work with.
>
> -dain
>
> On Apr 8, 2006, at 2:47 PM, Sachin Patel wrote:
>
>> Dain,
>>
>> I'm not sure if this helps or not... http://one-
>> jar.sourceforge.net/. Also I think equinox recently added support
>> for packaged bundles containing nested jars.
>>
>> - sachin
>>
>>
>> On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote:
>>
>>> On Apr 7, 2006, at 7:21 PM, John Sisson wrote:
>>>
>>>> Dain Sundstrom wrote:
>>>>>
>>>>> 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/%3c20060210144645.87917.qmail@web54302.mail.yahoo.com
>>>> %3e
>>>
>>> I'm planing starting with the emory university resource class
>>> loader which supports all the security stuff like URLClassLoader,
>>> but is public domain and much more modular. Specifically, I
>>> think it will be easy to implement nested jar support via
>>> unpacking to a temp directory.
>>>
>>> -dain
Re: Long Path Proposal
Posted by Dain Sundstrom <da...@iq80.com>.
one-jar only supports one level of nesting
I'm not a fan of the equinox code base. I normally spend forever
searching for stuff and then the code is very weird since they seem
to be supporting super old versions of java.
Thanks for the links, but the emory code will be easy to work with.
-dain
On Apr 8, 2006, at 2:47 PM, Sachin Patel wrote:
> Dain,
>
> I'm not sure if this helps or not... http://one-
> jar.sourceforge.net/. Also I think equinox recently added support
> for packaged bundles containing nested jars.
>
> - sachin
>
>
> On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote:
>
>> On Apr 7, 2006, at 7:21 PM, John Sisson wrote:
>>
>>> Dain Sundstrom wrote:
>>>>
>>>> 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/%3c20060210144645.87917.qmail@web54302.mail.yahoo.com%3e
>>
>> I'm planing starting with the emory university resource class
>> loader which supports all the security stuff like URLClassLoader,
>> but is public domain and much more modular. Specifically, I think
>> it will be easy to implement nested jar support via unpacking to a
>> temp directory.
>>
>> -dain
Re: Long Path Proposal
Posted by Sachin Patel <sp...@gmail.com>.
Dain,
I'm not sure if this helps or not... http://one-
jar.sourceforge.net/. Also I think equinox recently added support
for packaged bundles containing nested jars.
- sachin
On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote:
> On Apr 7, 2006, at 7:21 PM, John Sisson wrote:
>
>> Dain Sundstrom wrote:
>>>
>>> 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/
>> %3c20060210144645.87917.qmail@web54302.mail.yahoo.com%3e
>
> I'm planing starting with the emory university resource class
> loader which supports all the security stuff like URLClassLoader,
> but is public domain and much more modular. Specifically, I think
> it will be easy to implement nested jar support via unpacking to a
> temp directory.
>
> -dain
Re: Long Path Proposal
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 7, 2006, at 7:21 PM, John Sisson wrote:
> Dain Sundstrom wrote:
>>
>> 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/%
> 3c20060210144645.87917.qmail@web54302.mail.yahoo.com%3e
I'm planing starting with the emory university resource class loader
which supports all the security stuff like URLClassLoader, but is
public domain and much more modular. Specifically, I think it will
be easy to implement nested jar support via unpacking to a temp
directory.
-dain
Re: Long Path Proposal
Posted by John Sisson <jr...@gmail.com>.
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/%3c20060210144645.87917.qmail@web54302.mail.yahoo.com%3e
>
> 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
>