Aha!!
Excellent explanation!!.
Thanks
On 2/2/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
It has to do with the way input streams are encoded on the wire.
Assume you have the following method:
void deploy(InputStream module, InputStream deploymentPlan);
When a client invoked that method, they would get somthing like this
on the wire:
| ejb | invoke | 42 | deploy | ${module bytes} | ${plan bytes} |
On the server side we could read up to the first input stream, but
not the second since the bytes for the first input stream must be
read off of the socket before the bytes for the second input stream
can be accessed. In this case we could give a real input stream for
the first argument, and a proxy of the second that becomes active
once the first stream has been exhausted. The works until the user
decides to read the deploymentPlan stream first, which means the
module bytes must be read off the socked so we can get to the
deploymentPlan's bytes.
Another problem happens when you have methods like this;
void doSomething(InputStream module, int number)
With normal encoding the input stream bytes will be written to the
socket before the number is written. Since we must have the value of
the integer number before we invoke the method, we must read the
entire contents of the input stream before we can read the number and
thus before the method invocation.
A final complication is when people have input streams nested in
complex objects. For example:
void doSomethingElse(Map<String,InputStream> data);
In this case we must use special ObjectOutputStream hook on the
client side to replace all InputStream objects with our custom
RemoteInputStream:
protected Object replaceObject(Object obj) throws IOException {
if (obj instanceof InputStream) {
return new RemoteInputStream((InputStream)obj);
}
return obj;
}
-dain
On Feb 2, 2007, at 6:57 AM, Karan Malhi wrote:
> I think it is a good idea. I had one question though, why do we
> need to
> store data in a temp file in case of multilple input streams. If a
> single
> input stream could be handed over for invocation, what is wrong
> with handing
> over multiple input streams for invocation?
>
> On 2/1/07, David Blevins <[EMAIL PROTECTED]> wrote:
>>
>> Hey what do people think about this one?
>>
>> It's always bugged me that you can't use input streams in EJBs. It's
>> just too useful. For the case where there is a single input stream
>> in the arg list, we could do something pretty simple like have the
>> server reorder any other args so that the input stream is last in the
>> data sent from the client, then the server could literally just hand
>> off the input stream it has open with the client over as an argument
>> for invocation.
>>
>> For input streams as return types, we can just do the reverse of
>> this.
>>
>> If there were more than one input streams as arguments then we could
>> do a file upload style push to the server where the server reads in
>> each part to a temp file and then creates input streams to those and
>> passes them in as arguments for invocation.
>>
>> It's kind of a crazy idea, but I think this feature would just rock.
>> What do you think?
>>
>> -David
>>
>>
>
>
> --
> Karan Malhi
--
Karan Malhi
