Thanks for the reference to the usage of the extra properties. I was
not adding those. It turns out that GlassFish assumes that even empty
properties will always be there and does not check for a null byte array
when trying to extract them (which is what you get if there are no
properties). Adding an empty property list works. I'll add the real
one per your guidelines.
-Peter
Peter Williams wrote:
> Wow, ok this is weird. I guess I got bitten by 8408, though in my
> case, it occurred always, until I restarted the server (nothing was in
> the log).
>
> Now, it doesn't happen at all. Everything is working as expected, no
> matter how many times I restart. This is with both B55 and B56. If
> it happens again, I'll add a comment to #8408.
>
> -Peter
>
> Peter Williams wrote:
>> Thanks for all this information.
>>
>> The chunking error was from CLI. From my NetBeans code, it was a
>> different error (nondescript -- just a failure code with no message).
>>
>> However, I restarted the server to reset the log and upon doing so,
>> CLI deploys started working. Go figure.
>>
>> I'll dig into it tomorrow. I have some ideas.
>>
>> Thanks again for the insights.
>>
>> -Peter
>>
>> Tim Quinn wrote:
>>> Hi, Peter.
>>>
>>> I think earlier you wrote about getting some kind of chunking error?
>>>
>>> Is the NB plug-in doing this (copied from the RemoteCommand class
>>> which is what handle the http request and response):
>>>
>>> urlConnection.setChunkedStreamingMode(0); // use default value
>>>
>>> I was involved in inserting the payload handling into the
>>> CLIRemoteCommand (RemoteCommand's predecessor) which has survived
>>> intact in RemoteCommand, and I seem to recall having problems
>>> without that.
>>>
>>>
>>> Also, here is the wiki page that Kedar wrote describing the protocol:
>>> https://glassfish.dev.java.net/nonav/v3/admin/planning/j109/admin-cli.html#serverprotocol
>>>
>>>
>>> Here's a link to a separate page mostly focused on describing the
>>> REST interface for accessing configuration information (as opposed
>>> to performing actions such as deploying, etc.) but it says a little
>>> about the URL format:
>>>
>>> http://wiki.glassfish.java.net/attach/V3FunctionalSpecs/HTTPInterfaceForAdministartion.html
>>>
>>>
>>>
>>> I think that for what you are doing from the NB plug-in Kedar is the
>>> best source for up-to-date information, although what has been
>>> discussed on this thread so far is accurate as far as I know.
>>>
>>>
>>> - Tim
>>>
>>> Peter Williams wrote:
>>>> Hong Zhang wrote:
>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> Indeed that's a strange message.
>>>>>>> I have an up-to-date workspace (as of last night at least) and
>>>>>>> for me
>>>>>>>
>>>>>>> asadmin deploy --upload=true ...
>>>>>>>
>>>>>>> works...both from the same system as the server and from a
>>>>>>> physically separate one. I don't have a pure installation of a
>>>>>>> recent nightly or promoted build installed on my system. Sorry
>>>>>>> if I missed it - did you mention what build you are using?
>>>>>>
>>>>>> Client was B55 and B56. Server unknown, but probably B55.
>>>>>>
>>>>>>> Most of the server-side logic for the deployment processing
>>>>>>> and the uploaded file handling has been unchanged for some
>>>>>>> time. The CLI has gone through some recent work but I'm not
>>>>>>> seeing any problems.
>>>>>>> Did your server.log contain anything interesting from the failed
>>>>>>> deployment?
>>>>>>
>>>>>> I'll check...
>>>>>>
>>>>>>>
>>>>>>> Issue 8408
>>>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=8408
>>>>>>> describes an intermittent failure like what you've seen. Does
>>>>>>> the error persist if you retry the deployment? (The issue seems
>>>>>>> to indicate a first-time problem -- occasionally.)
>>>>>>
>>>>>> The error happened always.
>>>>>
>>>>> Is your archive pretty big?
>>>> No, only 2940 bytes.
>>>>> That message most times indicates a deployment time out (yes, we
>>>>> do need to figure out a way to make that error message more
>>>>> meaningful). If you try with a simple app, does it make a difference?
>>>> It's a default NetBeans web app - contains index.jsp, web.xml, and
>>>> sun-web.xml.
>>>>
>>>> Not going to get much simpler than that.
>>>>
>>>> -Peter
>>>>>
>>>>> - Hong
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - Tim
>>>>>>>
>>>>>>>>
>>>>>>>> -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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>