Hi, Hong:
2013/6/4 Hong Zhang <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.
Thanks
Jeremy
> Thanks,
>
> - Hong
>