[
https://issues.apache.org/jira/browse/QPID-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919372#comment-13919372
]
Rob Godfrey commented on QPID-5591:
-----------------------------------
bq. The attribute->field matching doesn't look to work for the attributes with
a '.' in them, there is mapping from the '_' in the getters in order to build
the attribute name from the method, but the reverse doesn't seem to be true.
Yeah... I want to kill those "attributes" anyway, but for the time being I
should at least provide the reverse mapping if they are present (don't think
that any of those are currently "automated" so that shouldn't really be an
issue - and I'd want to remove the technique before automating them).
bq. I wonder if we should restrict the field matching more, currently if you
make a mistake it will just run up the class hierarchy and find any field
happening to have the name. It should probably stop once it gets beyond the
appropriate classes, or be restricted to only consider specific fields, e.g
another annotation.
Yeah - it should stop at AbstractConfiguredObject I guess.... I did ponder
adding another annotation to be clear that the member in question was meant to
be automated... it seemed somewhat redundant, but maybe it is safer.
bq. We possibly shouldn't return null in the event it doesn't find a match,
just to avoid issues going unnoticed for longer.
yeah - fair point... I'll fix that
> [Java Broker] Move responsibility for setting attribute values to
> AbstractConfiguredObject
> ------------------------------------------------------------------------------------------
>
> Key: QPID-5591
> URL: https://issues.apache.org/jira/browse/QPID-5591
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: 0.27
>
>
> Allow attributes to be defined as being automatically set... that is
> AbstractConfiguredObject takes responsibility for setting memberVariables
> within the subclass which represent the perceived value of the attribute.
> The "actual" value of the attribute will still be returned from the map held
> by the AbstractConfiguredObject. Calling getAttribute will evaluate to the
> perceived value except where the attribute is marked as secure in which case
> non "system" subjects will only receive an obfuscated value
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
