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.
Not really. Just try "asadmin get '*'" and you'll know. It returns all
the attributes, both present and absent (and have default value) from
domain.xml. So, no, user does not have to refer to documentation just
for default values and names of attributes (who have default values).
>
> Why isn't this sort of change run through asarch?
It's more of a bug-fix or enhancement (or more importantly a compatibility
change).
>
> 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.
Thanks.
>
> 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
>