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.
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