8:24 a.m.
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.
All the other operations used in Alpha1 for deployment can easily be
mapped to detyped requests using [1]. That should be done for the
standalone mode case today or tomorrow.
- Brian
[1]
https://github.com/bstansberry/jboss-as/blob/detyped2/controller-client/s...
On 1/24/11 6:39 AM, Heiko Braun wrote:
How's ${subject} going to work?
Ike
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
2:29 a.m.
On Jan 24, 2011, at 3:24 PM, Brian Stansberry wrote:
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.
I am wondering how you distinguish different content types though this API?
Or do assume it's always a ZipInputStream? What reflects the file suffix? Is it
something like
"runtimeName=*.war"?
Ike
9:11 a.m.
On 1/25/11 2:29 AM, Heiko Braun wrote:
On Jan 24, 2011, at 3:24 PM, Brian Stansberry wrote:
> 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.
I am wondering how you distinguish different content types though this API?
On the server side, the deployment content repository just reads the
stream and passes the same bytes to a FileOutputStream.
Or do assume it's always a ZipInputStream?
Yes; when the repository later hands out the content for use in the
runtime, it assumes it's a zip.
What reflects the file suffix? Is it something like
"runtimeName=*.war"?
Yes. The normal pattern is name = runtimeName = foo.war. If the user
wanted two different foo.war in the system, it could be, e.g.
name = foo.war_v1
runtimeName = foo.war
The "name" bit is only used as the unique id within the management
layer. The deployers and other runtime services only see the
runtimeName; e..g the becomes the JEE application name.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4:29 p.m.
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
12:42 a.m.
+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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5056
days inactive
5059
days old
6 comments
2 participants
participants (2)
-
Brian Stansberry -
Heiko Braun