-
1. Re: MMB attribute change notifications
squirest Mar 6, 2002 6:45 AM (in response to squirest)While I'm at it... (by the way "it" is the cache of the model info so we're not screwing around with descriptors all the time).
Should the MMB descriptors, esp the attribute descriptors, contain *textual* representations of the values for fields?
I suspect the answer is no. Perhaps the better questions are:
Can I put a Long in as the value for the lastUpdatedTimeStamp field?
Can I expect the currencyTimeLimit I'm given to be a Long (or maybe it should be an Integer 'cause it's in seconds...)?
If this is discussed in the spec I can't find it. Pointers are helpful.
Trev -
2. Re: MMB attribute change notifications
squirest Mar 6, 2002 7:07 AM (in response to squirest)WRT attribute changes - duh, it's in the spec.
Trev -
3. Re: MMB attribute change notifications
adrian.brock Mar 6, 2002 7:27 AM (in response to squirest)> While I'm at it... (by the way "it" is the cache of
> the model info so we're not screwing around with
> descriptors all the time).
>
> Should the MMB descriptors, esp the attribute
> descriptors, contain *textual* representations of the
> values for fields?
>
> I suspect the answer is no. Perhaps the better
> questions are:
I don't think this is specified. Only thing I found was
a NOTE: in RequiredModelMBean.invoke(). I'm not
sure it is relevant or gives an answer.
>
> Can I put a Long in as the value for the
> lastUpdatedTimeStamp field?
>
> Can I expect the currencyTimeLimit I'm given to be a
> Long (or maybe it should be an Integer 'cause it's in
> seconds...)?
The javadoc of DescriptorSupport.isValid() says
they "must [be] Numerics", so I guess it can be
any java.lang.Number?
>
> If this is discussed in the spec I can't find it.
> Pointers are helpful.
> Trev
I see you found the AttributeChange bit :-)
Regards,
Adrian -
4. Re: MMB attribute change notifications
squirest Mar 6, 2002 8:46 AM (in response to squirest)Thanks Adrian.
Here's another one related to change notifications.
The docs for MMB getAttribute says that if no getMethod is present and the value is stale it should return the default value (or null if it's not defined).
So, if you do a setAttribute on an attribute which currently has a stale value and does not have a getMethod (note GET method, not setMethod) should the notification's oldValue be the "default" value?
I think the answer is yes (which by the way makes it easier to code).
Any other opinions?
Trevor -
5. Re: MMB attribute change notifications
adrian.brock Mar 6, 2002 9:26 AM (in response to squirest)I think that's what the spec says.
You do setAttribute, the value is stored in the descriptor
(unless the currencyTimeLimit is 0)
But a later setAttribute notifies using
oldValue==default value
if the value has become stale and there is no
getAttribute.
Regards,
Adrian -
6. Re: MMB attribute change notifications
squirest Mar 6, 2002 11:47 AM (in response to squirest)Ok, another notification related one.
Do we check the MMBInfo.getNotifications() array to make sure it lists AttributeChangeNotifications? If it's not there do we add one?
Trev -
7. Re: MMB attribute change notifications
squirest Mar 6, 2002 12:43 PM (in response to squirest)Ack.
I think I'm losing my mind. If an attribute descriptor has no getMethod and the currencyTimeLimit is 0 then, as I interpret the spec, getAttribute can *only* ever return the default value...
Is that right?
Trev -
8. Re: MMB attribute change notifications
adrian.brock Mar 6, 2002 12:52 PM (in response to squirest)Re: Attribute change notifications
Have a look at javadoc for RequiredModelMBean.getNotifications()does this imply
MBeanInfo().getNotificaitons() might not contain an entry for AttributeChangeNotification?
Re: No getAttribute and no caching
Yep, always the default value
Re: Losing your mind
Me too :-)
Regards,
Adrian -
9. Re: MMB attribute change notifications
juha Mar 6, 2002 1:14 PM (in response to squirest)> I think I'm losing my mind. If an attribute
> descriptor has no getMethod and the currencyTimeLimit
> is 0 then, as I interpret the spec, getAttribute can
> *only* ever return the default value...
>
> Is that right?
yes, the attribute behaves like a constant in that case.
-- Juha -
10. Re: MMB attribute change notifications
juha Mar 6, 2002 1:20 PM (in response to squirest)> Have a look at javadoc for
> RequiredModelMBean.getNotifications()does this imply
> MBeanInfo().getNotificaitons() might not contain an
> entry for AttributeChangeNotification?
No, it means the resource configuration (the mbeaninfo you set for the modelmbean) does not have to include these two notification types (the modelmbean implementation will add them for you).
-- Juha -
11. Re: MMB attribute change notifications
juha Mar 6, 2002 1:22 PM (in response to squirest)> Do we check the MMBInfo.getNotifications() array to
> make sure it lists AttributeChangeNotifications? If
> it's not there do we add one?
yes we add them, and you do it in the mmb implementation, see the XMBean in the book
-- Juha -
12. Re: MMB attribute change notifications
juha Mar 6, 2002 1:25 PM (in response to squirest)> Should the MMB descriptors, esp the attribute
> descriptors, contain *textual* representations of the
> values for fields?
>
RI implies textual representation is the norm, and you should always at least support this one. Numeric types can be supported as an optional feature.
-- Juha -
13. Re: MMB attribute change notifications
squirest Mar 6, 2002 3:00 PM (in response to squirest)> > is 0 then, as I interpret the spec, getAttribute
> > can*only* ever return the default value...
> >
> > Is that right?
>
> yes, the attribute behaves like a constant in that
> case.
Except not like a constant because you can still call setAttribute (if it's writable) which generates an AttributeChangedNotification that advertises a new value which you can never obtain via getAttribute(). -
14. Re: MMB attribute change notifications
juha Mar 6, 2002 3:32 PM (in response to squirest)yes, having a constant attribute means it has to be declared read-only, obviously.
-- Juha