Jerome,
Let me get this straight. You are saying -- Add every config element
and every Server element to the Habitat. Period. Don't do any checking?
Sounds good to me. It makes the parsing code much simpler. I'll go
edit out all my code that does the checks and let the model find the
problems later on at post-startup.
On 3/19/2010 8:06 PM, Jerome Dochez wrote:
> On Mar 19, 2010, at 5:45 PM, Byron Nevins wrote:
>
>
>>
>> On 3/19/2010 12:55 PM, Jerome Dochez wrote:
>>
>>> On Mar 19, 2010, at 10:30 AM, Byron Nevins wrote:
>>>
>>>
>>>
>>>> The code that parses domain.xml and fills the Habitat with config& server objects has been enhanced and is FINISHED.
>>>>
>>>> What it does:
>>>> • *All* configs are read in and added to the habitat.
>>>>
>>>>
>>> so how does it decide whether or not it should load all the config or just one ?
>>>
>>>
>> DomainXml has two constructors. One takes a server-name argument. The other one does not have that arg. In the latter case all configs are read. In the former case just one will be read.
>>
>> So -- further work needs to be done in the layer one level up. Right now it always calls the "DAS" version that does not take a server name.
>>
>>>
>>>
>>>> • All server objects are also added.
>>>> • 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() )
>>>>
>>>>
>>> what do you use for the check ? by using Element#reference() this should be done automatically.
>>>
>>>
>> The existing code did not do anything fancy. It simply checked for a config-ref and if it was null it would throw a RuntimeException.
>>
>> What I do now is semi-fancy:
>>
>> With a guaranteed one-pass parse of domain.xml it matches every server with the config that it references. If the config doesn't exist it is a fatal error.
>>
> I don't think this is the right way of doing this. the model is capable of maintaining its own integrity (of course, if you modify the domain.xml manually, you are on your own).
>
> By using the reference() feature of the @Element annotation, we would ensure that the config always exist.
>
>
>>>
>>>
>>>> • A config is allowed to have more than one server referring to it
>>>> • A config is not forced to have anything refer to it
>>>>
>>>>
>>> is there code enforcing this ?
>>>
>>>
>> Yes. See above...
>>
> same as above, this must be enforced by the model, not some code that runs on startup once...
>
>
>>>
>>>
>>>> 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.
>>>>
>>>> What this means:
>>>> We can add cluster and instance configs and any other configs -- and DAS will pick them up at boottime and they will be available in the Habitat.
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> 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