[jboss-as7-dev] Domain mode server launch command

[John O'Hara]

I have an updated version of the launch command taking into account the 
suggestions made below.

https://github.com/johnaoahra80/jboss-as/commit/de881403bdd8ea20fae89eea069177fa392e3373

I still have a question over the log number, the sequence of numbers 
that have been allocated to HostControllerLogger.java have been 
exhausted (10900-10939). I am not sure what number to allocate to the 
new log message.

Thanks

John

On 08/16/2012 03:52 AM, Brian Stansberry wrote:
> On 8/15/12 3:16 PM, Kabir Khan wrote:
>> On 15 Aug 2012, at 17:38, John O'Hara wrote:
>>
>>> I have an initial attempt at pulling this together;
>>>
>>> https://github.com/johnaoahra80/jboss-as/commits/launchCommand
>>>
> Great!
>
>>> A couple of things that I would be grateful for some guidance on is;
>>>
>>> 1 - I have created a PREFIX attribute for the Host Server model in the
> Please use launch-command-prefix as the attribute name. When users read
> the resource using the CLI, that name is more self-explanatory.
>
>>> host controller. The xml parser populates this attribute with any
>>> commands defined in <launch-command prefix="numactl --membind 1
>>> --cpubind 1"/>. Is this an acceptable/standard way of modifying the
>>> model for a host server?
>>>
> Instead of using the write-attribute operation, the parser should modify
> the "add" operation for the server-config and add a
> launch-command-prefix parameter.
>
>> In your DescriptionProvider, since the write attribute handler validator allows null and expressions (which was my advice, whether expressions are needed is up for discussion), you would need to add
>> root.get(ATTRIBUTES, PREFIX, EXPRESSIONS_ALLOWED).set(true);
>> root.get(ATTRIBUTES, PREFIX, NILLABLE).set(true);
>>
>> In the parser, again if expressions are needed you should use parsePossibleExpression()
>>
> We are converting most of the coding of the resources in our management
> model to use the ResourceDefinition and AttributeDefinition interfaces.
> I'll try tomorrow to get a patch done that converts this SERVER_CONFIG
> resource to using those interfaces. That will make doing all of this
> simpler.
>
>>> 2 - I have imported
>>> org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER into
>>> ModelCombiner.java so that I can log an INFO message if a launch command
>>> prefix has been defined. Is there a better place to log the message?
> No, ROOT_LOGGER is the one to use; it logs all the other messages
> related to the HC's activities controlling the lifecycle of servers.
>
>>> 3 - I have created a new info message in ModelCombiner.java,
>>> serverLaunchCommandPrefix, with id = 11990. This is an arbitrary id, are
>>> there any standards for assigning id's to messages?
>> The message id should be sequential from the previous one
>>
> The class javadoc for HostControllerLogger explains things a bit more.
>
>>> John
>>>
>>> On 08/14/2012 07:14 PM, Brian Stansberry wrote:
>>>> Then how about this:
>>>>
>>>> <launch-command prefix="numactl --membind 1 --cpubind 1"/>
>>>>
>>>> If we ever find a use case for a suffix, we just add the attribute.
>>>>
>>>> On 8/14/12 12:28 PM, John O'Hara wrote:
>>>>> I think the launch-command-prefix is probably more suitable, as
>>>>> ModelCombiner already does a good job at defining which java command to run.
>>>>>
>>>>> atm I can not think of a use case for a launch-command-suffix element
>>>>>
>>>>> re [1] - I noticed this up after I sent the email
>>>>>
>>>>> On 08/14/2012 06:03 PM, Brian Stansberry wrote:
>>>>>> That's along the lines of what I was thinking for the "different user
>>>>>> account" case.
>>>>>>
>>>>>> Something to think about is whether "java" should be in the
>>>>>> launch-command[1] value (with a default value of just "java".) If not
>>>>>> it's really a launch-command-prefix, and then is there a use case for
>>>>>> launch-command-suffix?
>>>>>>
>>>>>> I think using a separate child element for this instead of an attribute
>>>>>> is better.
>>>>>>
>>>>>> Another question is whether it makes sense to allow this to be
>>>>>> configured at the server-group level, with servers by default inheriting
>>>>>> that config. My vote is "no." KISS. If there is demand for doing it at
>>>>>> the server-group level, we'll here about it and can add it later.
>>>>>>
>>>>>> As for validation, I doubt we can do much there. I think this would be
>>>>>> an advanced feature where users are going to have to be careful and test
>>>>>> things.
>>>>>>
>>>>>> [1] Note our schema uses lower case names with "-" as a separator, not
>>>>>> camel case. So "launch-command" not "launchCommand".
>>>>>>
>>>>>> On 8/14/12 11:49 AM, John O'Hara wrote:
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).