dev@glassfish.java.net

Re: request asarch review for deploy command enhancement in GlassFish

From: ÂÀËÎƽ <lvsongping_at_gmail.com>
Date: Thu, 30 May 2013 09:40:39 +0800

2013/5/30 Bill Shannon <bill.shannon_at_oracle.com>

> ÂÀËÎƽ 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.
>
 [Jeremy] Pls igore about what I have presented. Yes, the whole point of
the deployuri command was to send the URI string to the server and have the
server download the app. Sorry about that!