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

[Heiko Braun]

+1 
A general approach to retrieve content is a good idea. This way we could also the content type




On Jan 25, 2011, at 23:29, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev