Wait a minute, lots of people will be hand-editing domain.xml. And
only last week when I raised the "not an interface" issue, Kedar
insisted it was in fact a de-facto interface.
On Sep 23, 2008, at 3:02 PM, Jerome Dochez wrote:
> Lloyd Chambers wrote:
>> If the user wants to change a value, s/he's now got to refer to *
>> documentation* just to remember the correct attribute name and
>> spelling of the attribute. And if it's wrong, maybe things blow up
>> (eg 'jndiname' vs 'jndi-name'). That sucks.
>>
>> Why isn't this sort of change run through asarch?
> because just like Kedar said below, we never authorized direct
> access to the domain.xml therefore there is no change of interface
> or expectation, if all internal clients go through the config-api
> they should get the value, since amx goes through the config-api, it
> should get the default value and there is therefore no change in
> contract.
>>
>> There are two possibilities for the 'null':
>> - a new bug in AMX that generates null when it shoudn't
>> - the ConfigBean is returning null or throwing an exception when it
>> didn't before.
>>
>> I will investigate.
>>
>> Lloyd
>>
>> On Sep 23, 2008, at 2:43 PM, Kedar Mhaswade wrote:
>>
>>>
>>>
>>> Lloyd Chambers wrote:
>>>> I think there might be a problem with Jerome's changes. Working
>>>> with the web-app-config, I found that even explicitly setting
>>>> 'type' to its default value *did not cause any attribute to
>>>> appear in domain.xml*. This is probably the same issue.
>>>
>>> I did stumble on this one when Jerome made the changes in that he
>>> does
>>> not write to domain.xml an attribute if its value is same as the
>>> default
>>> value. So, from what code does, this is expected. He said it is ok
>>> not
>>> to write to domain.xml even if you, as a client, has set a value
>>> explicitly,
>>> but it is the same as default. I think it is reasonable not to
>>> actually
>>> write it to domain.xml since we don't have any commitment to
>>> people who
>>> directly read/parse domain.xml (this is what I told him during
>>> review).
>>>
>>> But I am not sure why the default value when queried via AMX is not
>>> available. Thus, even if <http-listener id="http-listener-1"> exists
>>> in domain.xml, "enabled" attribute should have been returned as
>>> "true"
>>> since @Configured declares it so. So, I guess I am not
>>> understanding why
>>> AMX does not return it.
>>>
>>>> AMX returns what the ConfigBean supplies. So if 'null' is coming
>>>> back, it means that the ConfigBean is returning null. This is
>>>> broken; if there is a default value it should still be populated
>>>> with its default. This DIFFERS from the case of an optional
>>>> value, where null means it hasn't been specified.
>>>> The only reasonable expectation is that calling getEnabled() for
>>>> the following will always return "true" (unless changed to false):
>>>> @Attribute(defaultValue="true")
>>>> public String getEnabled();
>>>> The value 'null' can be expected here if it has not been set:
>>>> @Attribute
>>>> public String getWarmToday();
>>>> Lloyd
>>>> On Sep 23, 2008, at 1:57 PM, Kedar Mhaswade wrote:
>>>>>
>>>>>
>>>>> Anissa Lam wrote:
>>>>>> Hi,
>>>>>> I am looking at issue# 6262 regarding launch link disappers in
>>>>>> admin console for running deployed web apps.
>>>>>> I think there is a side effect of default attribute not
>>>>>> specified in domain.xml, as Jerome made the changes last week.
>>>>>> For the case of http-listener, enabled attribute is not
>>>>>> specified.
>>>>>> <http-listener default-virtual-server="server" server-name=""
>>>>>> address="0.0.0.0" port="8080" id="http-listener-1">
>>>>>> In my code, i tested if httpListener.getEnabled() returns
>>>>>> "true". If it doesn't return true, the code thinks it is not
>>>>>> enabled. AMX is returning null which is correct, i guess. This
>>>>>> is just a specific case, and maybe I can put in the code saying
>>>>>> returning null means enabled, which i really want to avoid.
>>>>>
>>>>>
>>>>> I agree. But why is AMX returning null?
>>>>> If the default value is present, shouldn't AMX be returning it,
>>>>> e.g.
>>>>> "true" in this case for HttpListener which has:
>>>>>
>>>>> @Attribute (defaultValue="true", dataType=Boolean.class)
>>>>> public String getEnabled();
>>>>>
>>>>> I do get:
>>>>> configs.config.server-config.http-service.http-listener.http-
>>>>> listener-1.enabled=true
>>>>>
>>>>> on
>>>>>
>>>>> querying:
>>>>> asadmin get "*" | grep http-listener
>>>>>
>>>>> -Kedar
>>>>>
>>>>> (I also think that this was rather late binding change though it
>>>>> trimmed the
>>>>> domain.xml tremendously).
>>>>>
>>>>>> For boolean attribute, the default may be true or may be false.
>>>>>> It is very hard for me to check for null and then ask for the
>>>>>> default value, compare that and made decision for every
>>>>>> attribute.
>>>>>> We can either put back the default value if it is boolean, or
>>>>>> AMX should return the default value if the attribute has no
>>>>>> value specified in domain.xml.
>>>>>> Btw, most of the admin gui pages now doesn't show any value,
>>>>>> because we are displaying whatever AMX returns for the
>>>>>> attribute, and since the attribute is not specified in
>>>>>> domain.xml, i am getting lots of empty strings or null, and
>>>>>> that is what user sees. This is very different than before.
>>>>>> Please see attached image.
>>>>>> Maybe AMX code should return the default value if the attribute
>>>>>> is not specified in domain.xml ? what do you think ?
>>>>>> thanks
>>>>>> Anissa.
>>>>>> ------------------------------------------------------------------------
>>>>>> ------------------------------------------------------------------------
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>