[jboss-as7-dev] cli

[David M. Lloyd]

On 02/14/2011 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.

Well any host management socket should know how to answer host changes, 
domain changes, and server changes; it should be one protocol on one 
socket with the only differentiator being the address in question.

For host changes, that host's configuration change is effected 
immediately.  For domain changes, if the node is the DC it can handle it 
locally, else it'd forward on (on the user's behalf, presumably).  For 
server changes, it'd require that the caller has the appropriate 
credentials (some operations, like reads and most runtime-only changes, 
can be carried out by users, while others, like server model changes, 
may only be carried out by the HC).
-- 
- DML