On 6/4/2013 11:03 AM, ÂÀËÎƽ wrote:
> Hi, Hong:
>
>
> 2013/6/4 Hong Zhang <hong.hz.zhang_at_oracle.com
> <mailto:hong.hz.zhang_at_oracle.com>>
>
> Hi, Bill
>
>
> On 6/3/2013 6:49 PM, Bill Shannon wrote:
>
> Hong Zhang wrote on 05/31/2013 06:48 PM:
>
> On 5/31/2013 7:31 PM, Bill Shannon wrote:
>
> ÂÀËÎƽ wrote on 05/29/13 21:38:
>
> Hi, Bill, Craig, Hong,Sahoo:
> After the disscusstion recently, I pick up some of
> the disscussion above
> and list as follows to see whether there still
> exist any other suggestion:
> A) An option to disable the deployuri command
> completely should the
> administrator be concerned
> B) An option to limit the URI types that would be
> allowed
> C) Allow for specification of a "sandbox" area use
> as the download location to
> better control permissions, ownership, quotas,
> disk space, etc.
> D) Allow for the possibility to include hooks for
> virus scanners or other
> intrusion detection software.
> As to A) and B):
> Just regard the tips as Bill had mentioned that we
> should create an attribute
> or property set with "asadmin set", If different
> administrators had different
> privileges in the future, we could restrict the
> use of the "asadmin set"
> command. I think the most important question here
> is to how to use a
> local-only command to control this option("asadmin
> set")?
>
> I can't think of any other cases where we do anything
> like this, so I'm not sure
> we have a precedent to follow. Perhaps someone else
> here has some ideas?
>
> I think "asadmin set" can be used to modify most
> anything in domain.xml, so I'm
> not sure there's a way to include this configuration
> information in domain.xml
> but hide it from "asadmin set".
>
> Another option is to store this information in a
> separate config file, and have
> a local asadmin command to manipulate that config
> file. That seems like
> overkill, so I'm hoping someone else will have a
> better idea
>
> As to C):
> Regard to the tips as Hong, How about regarding
> the directory of
> domains/<domain_dir>/applications/__internal/<app_name>/
> as a directory to
> store the application download remotely. Of
> course, the operation to execute
> the download will be executed during the server side.
>
> Does that directory already exist? What's it used for?
>
> This is an existing directory where we store/stage the
> uploaded applications today.
>
> When an application needs to be uploaded for a deployment,
> the application is
> first uploaded to a temporary directory under
> domains/domain1/applications by
> the payload manager, such as:
>
> domains/domain1/applications/xfer-6697881642146365610/
>
> and then moved to this internal directory for staging:
>
> domains/<domain_dir>/applications/__internal/<app_name>/
>
> So we could do something similar for this case, upload to
> a tmp directory and
> then later move to the staging directory, or directly
> place it in the staging
> directory.
>
> What operations are done on the application when it's in the
> staging
> directory, before it's moved to the final directory?
>
> No, there is no final directory (maybe it's the wrong term for me
> to call it staging directory). This directory is to preserve the
> files uploaded during deployment so the sync logic can use them to
> sync the files to remote instances.
>
>
> I'm just trying to figure out why we need three directories -
> an upload/download directory, a staging directory, and the
> "installed" directory.
>
> Is the archive stored in the upload directory, and then
> expanded into the
> staging directory?
>
> The archive is first uploaded to the upload directory (when
> needed) and then expanded into the installed directory
> (applications/<app_name>/). The file is then moved (or copied) to
> applications/__internal/<app_name> directory for sync logic to
> use. We had a discussion on this back in 3.1 when we implemented
> the clustering/synchronization logic.
>
> [Jeremy] As we download the remote application during the server side,
> In my human option, I think we can create an additional directory
> called _downloadAsUri under the directory of
> domain/doman_dir/applications to restore the file downloaded remotely.
> I don't think it will affect the original syntax about the deployment
> comp.
I don't know if we need a new sub directory, we can probably just create
a temp directory under applications/ like how the uploaded application
is handled and delete the temp directory afterwards.