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
>