I think I may have missed something as well? If the GlassFish server
downloads the application on behalf of the "client" then I'm suggesting
a separate "sandbox" area for this download purpose. Browsers have
download folders where things go by default and those are typically
separated for each user.
Having different permissions, quotas, etc. are not so much about access
from GlassFish server itself but potentially from other processes/uids
in the system such that the downloaded content would not be used outside
of the intended purpose. My suggestion is based on providing potential
for more flexibly in cases where administrators maybe concerned about
resource handling and the existing folder may already be sufficient.
-------- Original Message --------
Subject: Re: request asarch review for deploy command enhancement in
GlassFish
From: Bill Shannon <bill.shannon_at_oracle.com>
To: 吕宋平 <lvsongping_at_gmail.com>
CC: Craig Perez <craig.perez_at_oracle.com>, dev_at_glassfish.java.net,
hong.hz.zhang_at_oracle.com
Date: Wednesday, May 29, 2013 5:47:38 PM
> 吕宋平 wrote on 05/29/13 07:58:
>> [Jeremy]Here's some points of mine:
>> 1). Do you still remember the .gfclient exists in the directory of
>> $User? Maybe we can create a file called .download_apps as a staging
>> directory under the same directory of .gfclient.
> Maybe I misunderstood...
>
> If the proposal is to have the *client* download the app, store it
> locally, and then upload it to the server in the usual fashion, I
> understand why you would need a staging directory.
>
> But I thought the whole point of the deployuri command was to send the
> URI string to the server and have *the server* download the app. In
> that case, I don't understand how a staging directory helps.
>
>> 2). If the name of the application we downloaded remotely is same
>> with the application exists in the staging area, we can delete the
>> original application in the staging area and continue to download the
>> remote application after being "verified"(if the app is downloaded to
>> this staging area and doesn't exceed the filesystem quota we would
>> consider it ok to deploy it to the real app directory)
> If you're trying to deploy a new app with the same name as an existing
> app, the deployment should fail before downloading the app.
>
> If you're redeploying an app, the new version should be
> uploaded/downloaded into a tmp location before removing the old
> version. (I think the current upload approach always uses a tmp
> directory.)
>
>> Anyway, if we don't create a directory automatic, I think the
>> following suggestion will be helpful:
>> 1). From the client side, we can also support an option called
>> --localTemp as a primary parameter to store the application
>> downloaded remotely.
> If we're going to download it to the client only to upload it to the
> server, why don't we just let the user use "curl" or "wget" to
> download it to the client and store it wherever they want, then use
> the existing deploy command to upload it? Why would we need a new
> deployuri command for this?
>
>> 2). From the administrator side, we can support a virus scanning
>> to specify which directory to store the application downloaded remotely.
>> 3). Continue the operation to deploy the application.
> Again, a general hook to allow virus scanning is fine, but I don't see
> any reason we can't just store the app wherever we would normally
> store it, point the virus scanner at it, and if it passes then
> complete the deployment.
>