dev@glassfish.java.net

Re: request asarch review for deploy command enhancement in GlassFish

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Wed, 29 May 2013 14:47:38 -0700

吕宋平 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.