On Thursday 12 July 2012 04:19 PM, Ancoron Luciferis wrote:
> On 07/12/2012 07:42 AM, Sahoo wrote:
>> Hi Ancoron,
>>
>> I have not looked at your implementation yet. Based on what you have
>> written, it sounds impressive. It does solve the issue of exposing the
>> underlying OSGi commands to end user in a very extensible way and we
>> should definitely consider this for GlassFish. I have one outstanding
>> issue though. I am still looking for a way to provide a Gogo shell like
>> interface to user as it allows user to much more powerful scripting. Can
>> we add something like an osgi-shell command and which just gives works
>> as an I/O mechanism for the underlying shell running in the server?
>>
>> Thanks,
>> Sahoo
> Well, I already thought about something like this, but also didn't have
> enough time to take a deeper look. As far as I know there will be a
> problem because the remote side of asadmin is not ready for streaming
> input/output yet, so the first step would be to handle the "interactive
> shell" part with a local command, that just issues separate remote commands.
>
> Shouldn't be too hard to do something like this. Give me a second, or
> two... :)
>
> However, I fear that in this case the command execution delay imposed by
> the asadmin stack will still be there as the local asadmin side seems to
> introduce a one second delay to every command. That's why I already
> wrote some python scripts for batch tasks which directly use the
> asadmin/management rest interface instead of the client (at least in
> case I know the remote target), which is much faster.
>
> Cheers,
>
> Ancoron
>
I look forward to what you come up with. Don't worry about the latency
introduced by asadmin cli.
Thanks,
Sahoo