[jboss-as7-dev] Remote deployment through deployment API

[Brian Stansberry]

On 1/24/11 8:24 AM, Brian Stansberry wrote:
> The design issue we need to decide on (thanks for the thread to do it ;)
> ) is how to upload content to the DC or standalone AS. The client-side
> API in Alpha1 included a method that was used for this:
>
> /**
>    * Add the content for a deployment to the domain controller.
>    *
>    * @param name The deployment name
>    * @param runtimeName The runtime name
>    * @param stream The data stream for the deployment
>    * @return The unique hash for the deployment
>    */
> byte[] addDeploymentContent(String name, String runtimeName, InputStream
> stream);
>
>
> The client side impl of that API then read from the stream and pushed
> the bytes to the server.
>
> (There were convenience utilities as well, but that's another topic.)
>
> The current detyped client side API[1] has no such stream-based method.
> With what it exposes, users would have to create operation requests
> using ModelNode, and either a) pass the content as a byte[] param in the
> operation request or b) pass a String param that represents a URL from
> which the server can read the content (URL must be accessible to the
> server).
>
> The simplest solution is just to add "byte[] addDeploymentContent(String
> name, String runtimeName, InputStream stream)" back into the client side
> API.  That's what I'll do unless we reach a different decision in the
> next day or two.
>

What looks like a better approach came up today:

dmlloyd: bstansberry / kkhan : on a side topic - I was thinking that 
deployment requests could/should have a third way to specify the content
[3:55pm] dmlloyd: a transport-specific "attachment" name
[3:55pm] dmlloyd: on HTTP it'd be a multipart file attachment, on 
Remoting it'd be an independent stream
[3:57pm] bstansberry: how does that work?
[3:58pm] dmlloyd: in the HTTP case, the protocol handler takes note of 
the extra content and attaches it to a context of some sort for the 
operation to query
[3:59pm] dmlloyd: in the Remoting case, the operation's query of the 
context would trigger the remote stream to be consumed in the background 
as the operation consumed data from the stream
[4:01pm] bstansberry: ok, so the ModelController execute methods will 
take a context param
[4:03pm] bstansberry: and the ModelController client can have overloaded 
methods that take a stream
[4:04pm] bstansberry: that's better; I didn't like having a specialized 
method for a single use case
[4:04pm] bstansberry: even if we only end up with a single use case, it 
still smells funny
[4:04pm] dmlloyd: a stream or streams even
[4:04pm] dmlloyd: the future may reveal many use cases for uploading content

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat