[jboss-as7-dev] cli

[Brian Stansberry]

On 2/14/11 12:11 PM, Kabir Khan wrote:
>
> On 14 Feb 2011, at 17:51, Brian Stansberry wrote:
>
>> Apologies it's taken so long to give you feedback; I was out sick Friday.
>>
>> I'll probably post a series of messages over the course of the week as I
>> continue to experiment. I'm already using this to find bugs in the core
>> stuff (e.g. inherited operations don't seem to be working anywhere other
>> than the root address).
>>
>> On 2/11/11 9:57 AM, Alexey Loubyansky wrote:
>>> Just FYI, in case of discussions, etc, I'm on PTO next week.
>>>   From Sunday to Thursday afternoon I won't have reliable Internet access.
>>>
>>> On 02/11/2011 04:50 PM, Alexey Loubyansky wrote:
>>>> I'd like to give a status update on what I've done so far, collect some
>>>> feedback and get a sense of direction for the roadmap.
>>>>
>>>> So, so far it's a primitive thing. There is a script jboss-admin.sh(bat)
>>>> under the JBOSS_HOME/bin. It starts a cli as a module (I found it easier
>>>> this way).
>>>>
>>>> First thing to do is to connect to the server. It's done with
>>>>
>>>> /connect [host]:[port]
>>>>
>>>> Default host is localhost, default port is 9999.
>>>>
>>
>> On master, Kabir introduced a notion of different types of clients
>> (DOMAIN, HOST, STANDALONE) which are implemented by passing an enum to
>> ModelControllerClient.Factory.create(). We need to think through how
>> that relates to this; whether that distinction is required and how to
>> express it in the CLI.
>>
>> The actual core API is the same between DOMAIN, HOST, STANDALONE (i.e.
>> operations expressed in DMR and passed to the managed process and
>> operation results in DMR are passed back); the real difference is just
>> what the expected addresses and operations are. Right now the enum is
>> just used to check that the client is connecting to the expected kind of
>> process. Conceivably we don't need the DOMAIN/HOST/STANDALONE enum and
>> we just count on users knowing what they are doing.
>
> The reason I added that was the host management socket. If the DC is local, both HC and DC requests will come in on the same socket. We need some differentiator to know if a request should go to the HC or the DC.
>

Ok. The core requirement for that case is that the DC make clear that 
it's requests are from the DC. It's not required that an external user 
says that it's requests are not from the DC; i.e. some kind of default 
behavior could be used.

It might make sense to have CLI users make clear their intent anyway, so 
I'm not suggesting you change anything at this point.

If we don't require CLI users to declare their intent, then the /connect 
command should make clear what kind of process was connected to (beyond 
the address:port). Actually, it should do that no matter what.


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat