I could definitely add an env. variable for pretending to be a server
instance. I tested it manually and everything worked for a
single-server scenario. The REST URL that Jerome gave in his talk on
Tuesday is a very useful tool for this...
On 3/19/2010 11:36 AM, Bill Shannon wrote:
> Byron Nevins wrote on 3/19/10 10:30 AM:
>
>> The code that parses domain.xml and fills the Habitat with config&
>> server objects has been enhanced and is FINISHED.
>>
>> What it does:
>>
>> 1. *All* configs are read in and added to the habitat.
>> 2. All server objects are also added.
>> 3. It checks and verifies that every server has a config-ref and that
>> that config-ref exists. If not it is a fatal error and V3 will
>> hang. (it is impossible to make V3 exit cleanly without halt() )
>> 4. A config is allowed to have more than one server referring to it
>> 5. A config is not forced to have anything refer to it
>>
>> What About Server instances?
>> This code is written and tested but not used yet because we don't have
>> instances yet! Once we have start-instance then that instance willl
>> only read its own config from domain.xml.
>>
> For testing purposes, can you use an environment variable to specify
> the name of the instance to start (vs. the default "server" for DAS)?
> For example:
>
> AS_INSTANCE=instance1 asadmin start-domain
>
> Real start-instance support will need to know to find the instance
> directory under the node agent directory, of course, but this hack
> would prove that you could run as a particular instance.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
>
--
Byron Nevins - Sun Microsystems, Inc.
Home: 650-359-1290
Cell: 650-784-4123
Sierra: 209-295-2188