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?
>
> 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.
or AMX is using a low-level API to access attributes which does not take
default value into account. that would be my guess...
>
> 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
>