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