geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: More Build Questions?
Date Tue, 20 Sep 2005 17:49:53 GMT
I think non-persistent attributes are not manageable and I thought the 
code followed this.  I'll try to figure out what is going on.

The question of whether a persistent attribute not marked explicitly as 
non-manageable for which we currently don't have an accessible property 
editor is more complicated, since the answer can change depending on 
what classes are available rather than anything to do with the 
attribute.  I'd prefer to call them manageable but obviously not read 
or write their values from the mangeable attribute store.

david jencks

On Sep 20, 2005, at 1:41 PM, Dain Sundstrom wrote:

> It is my understanding that an manageable attribute is defined as an 
> attribute *not* tagged as non-manageable for which we have a property 
> editor for the type.  If we don't have a property editor, it isn't an 
> error; it simply was never a manageable attribute.
> Of course my understanding of the definition of "manageable attribute" 
> maybe wrong.
> -dain
> On Sep 20, 2005, at 9:48 AM, Aaron Mulder wrote:
>> But the attributes in question are not persistent, so it's not 
>> meaningful to call them manageable.
>> What happens if you assign a value to the "manageable attribute" for 
>> the number of requests so far and the average response time for the 
>> Jetty container?  What are you going to meaningfully assign to the 
>> request log reference?  How about the kernel or ObjectName?  I don't 
>> think it makes sense to make any nonpersistent attributes manageable.
>> Aaron
>> On 9/20/05, Dain Sundstrom <> wrote: On Sep 20, 2005, at 
>> 6:42 AM, Aaron Mulder wrote:
>> > The error about RequestLog can be ignored.  I put in a fix for the
>> > symptom last night, but the underlying problem is that we're trying
>> > to make too many attributes manageable.  Still, the only effect is
>> > that message, it doens't actually prevent anything from working.
>> I don't think the problem is we're trying to make too many attributes
>> manageable.  I think the problem is when we discover an attribute
>> that we cannot save because there is no property editor for it, it is
>> logged at ERROR.  Since this is a normal and expected situation, it
>> should be logged at DEBUG.
>> -dain

View raw message