Hi, Peter.
I've included Kedar explicitly as I believe he's the owner of the admin
protocol between the client and the server and he may have further
thoughts on this. At one point there were plans to revise how uploads
and downloads were handled but I think what I'm about to describe is
accurate for the current implementation.
If you are really interested, the relevant logic starts in the
RemoteCommand class in the admin/cli module. This is the class which
converts a CLI command and its arguments into the HTTP request and sends
it, and accepts the HTTP response and acts on it. Basically, what
happens is this.
If the command contains any arguments declared to be of type File and if
the option --upload is specified on the command (regardless of which
specific command it is), then the file arguments are placed into the
payload of the HTTP request and are uploaded that way. Currently, if at
least one file is being uploaded then the payload in the request is
written as a JarOutputStream, with one JarEntry for each uploaded file.
Some extra data (as defined in the ZipEntry class) is stored as a
Properties object with each entry to convey added info about each part
of the payload:
(prop name) = (value)
"data-request-type"="file-xfer" (so the server knows exactly what to do
with this segment)
"data-request-name"= option value entered by the user for this file -
basically the path to the file on the client system
"last-modified" = lastModified from the file being uploaded - the long
value formatted as a String
The MIME type is application/zip. The http method is indeed Post for
requests containing uploads.
If any files are returned (for example, the "deploy --retrieve localDir
..." option or the get-client-stubs command) then they come back to the
client in just the same format, as one or more ZipEntry pieces of the
payload.
I know you want to stay as independent as possible of specific GlassFish
modules. Even so, the common/common-util module contains the
implementation of the payload-related classes which the RemoteCommand
class uses on the client side and which the server uses as well. Using
those would simplify the logic in the plug-in at the cost of adding that
dependency, obviously.
Hope this helps some.
- Tim
Hong Zhang wrote:
> Hi, Peter
> No, the archive deploy should work, otherwise all the QL tests
> would fail. ;-)
>
> Can you provide the details of the cli commands you tried to use?
>
> Tim: can you follow up with Peter on this as you are more familiar
> with the upload part of the deploy?
>
> Thanks,
>
> - Hong
>
>> I tried to deploy with CLI (old and new syntax) and I get
>>
>> com.sun.enterprise.cli.framework.CommandException: remote failure:
>> Invalid chunk header
>> Command deploy failed.
>>
>> So archive deploy is not working? Or I made a mistake, in which case
>> this error message is not very helpful.
>>
>> -Peter
>>
>> Peter Williams wrote:
>>
>>>
>>> Hong Zhang wrote:
>>>
>>>> Hi, Peter
>>>> What kind of error did you get? Did this just stop working
>>>> recently or it has never worked?
>>>
>>> I don't know. I've never tried it before.
>>>
>>> Can you comment on my interpretation of requirements? I guess I can
>>> look at CLI client if this works there (I haven't tried that, but I
>>> presume it does).
>>>
>>>> We don't have an upload option in the DeployCommandParameters
>>>> in the server side (the upload option for admin cli case is handled
>>>> by the client side).
>>>
>>> That's fine. Given that it can be inferred from the POST request
>>> type, it would be redundant anyway.
>>>
>>> -Peter
>>>
>>>> This is probably why the url with the upload option does not work.
>>>>
>>>> Thanks,
>>>>
>>>> - Hong
>>>>
>>>> Peter Williams wrote:
>>>>
>>>>> I'm working on remote (or just archive) deploy to V3 from NetBeans
>>>>> and having trouble with the deploy command
>>>>>
>>>>> I've been given the impression that the format is as follows -- is
>>>>> correct?
>>>>>
>>>>> URL - no rules - I'm guessing at this point but I would have
>>>>> thought something like
>>>>> "http://$server:$port/__asadmin/deploy?name=$name&upload=true"
>>>>> would have been sufficient. And since it's a POST request,
>>>>> perhaps even upload is redundant.
>>>>> Request type - POST
>>>>> Content type - application/zip
>>>>> Body - binary zip file containing the archive to be deployed (e.g
>>>>> war file, ear file, etc).
>>>>>
>>>>> I haven't been able to get this to work --
>>>>>
>>>>> The CLI deploy command has a "upload" option documented, but
>>>>> including this over the HTTP api causes an error.
>>>>> The HTTP api is requiring a path parameter though what that could
>>>>> possibly mean for remote deployment escapes me. If I refer to a
>>>>> valid local (to the server) file, the server cheats but if I refer
>>>>> to an invalid file, the command is failed.
>>>>>
>>>>> Does anyone know if this works and/or what the requirements are?
>>>>>
>>>>> -Peter
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>