Seeing recent emails on this topic, I realized that I did not provide
an update to the group.
Bill and I discussed the pros and cons of the two approaches that were
debated on this thread. Though, both approaches could solve the stated
problem, having an option to provide asadmin options in a separate
configuration file(s) could ease the operation management in an
enterprise setting. If there is an existing code that performs similar
functionality, Bill would try to leverage that.
Sorry for the delay.
On Wed, Jul 15, 2009 at 10:00 AM, Bill Shannon<bill.shannon_at_sun.com> wrote:
> I don't understand why this doesn't scale.
>
> Everywhere you would've had foo.config and used "asadmin --config foo.config"
> just have a fooasadmin and use fooasadmin instead.
>
>
> Vishal Mehra wrote on 7/15/09 6:40 AM:
>> Thanks Bill, I am aware of these techniques and they work fine in an
>> environment with limited number of DAS/instances but when we are
>> working with 10s and 100s of instances, IMHO, having another way to
>> provide options would be better.
>>
>> On Wed, Jul 15, 2009 at 12:18 AM, Bill Shannon<bill.shannon_at_sun.com> wrote:
>>> Vishal Mehra wrote on 7/14/09 3:29 PM:
>>>> Bill,
>>>>
>>>> Perhaps, this is out of the scope of the current implementation,
>>>> however, it would be good feature to have (RFE). In large enterprise
>>>> settings, wherein we are dealing with multiple instances of app
>>>> servers and clusters, providing the program options can be tedious
>>>> even if they are well scripted. Few programs options can run into
>>>> multiple lines and therefore it becomes challenging to manage them
>>>> especially when there are changes to the cluster topology, and/or to
>>>> the network. IMHO, it would nice to provide a configuration file as a
>>>> parameter to the asadmin command. The configuration could contain
>>>> program options as name/value pair. At run time, appropriate options
>>>> file(s) can be provided as a parameter.
>>>>
>>>> for example, asadmin_config_file1 could look like
>>>> host 127.0.0.1
>>>> port 4848
>>>> user admin
>>>> passwordfile somefile
>>>> secure false
>>>>
>>>> and then the asadmin command would like
>>>>
>>>> asadmin -config_file=asadmin_config_file <program>
>>>>
>>>> Even in a developer environment, developers would not have to specify
>>>> these options each time they run the asadmin command. They can set it
>>>> once and forget it.
>>>>
>>>> if you believe there is a value add to the above approach, perhaps, we
>>>> can extend the concept to create options hierarchy i.e. one (base)
>>>> option file is extended by another option file.
>>> There's two simple ways to solve this without any changes to asadmin.
>>>
>>> 1. Create a shell alias or script. For example:
>>>
>>> alias myasadmin="asadmin --host myserver --port 1234"
>>>
>>> or
>>>
>>> #!/bin/sh
>>> exec asadmin --host myserver --port 1234 "$@"
>>>
>>> 2. Set these program options as environment variables:
>>>
>>> export AS_ADMIN_HOST=myserver
>>> export AS_ADMIN_PORT=1234
>>>
>>> I think either of these is easier than using a config file and having
>>> to specify it for each command.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>