If you've already started up a server running a single instance
config that's not "server", then ignore my suggestion.
Byron Nevins wrote on 3/19/10 5:47 PM:
> 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
>>
>>
>