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
>