[
https://issues.apache.org/jira/browse/QPID-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919363#comment-13919363
]
Robbie Gemmell commented on QPID-5591:
--------------------------------------
https://svn.apache.org/r1573336
===============================
- This appears to be unused, (and very similar to the getValue() method above
it).
{noformat}
@@ -632,6 +754,22 @@ public abstract class AbstractConfiguredObject<X extends
ConfiguredObject<X>> im
Object o = attributeMap.get(_name);
return _converter.convert(o);
}
+
+ public T get(final AbstractConfiguredObject<?> object)
+ {
+ try
+ {
+ return (T) _getter.invoke(object);
+ }
+ catch (IllegalAccessException e)
+ {
+ throw new ServerScopedRuntimeException("Unable to access
attribute " + getName() + " on configuredObject type " +
+ }
+ catch (InvocationTargetException e)
+ {
+ throw new ServerScopedRuntimeException("Unable to access
attribute " + getName() + " on configuredObject type " +
+ }
+ }
}
{noformat}
- This will fail if 'o' is null. I don't expect that comparison will ever
happen, but I saw you made that change elsewhere recently so... :)
{noformat}
@@ -1408,7 +1385,7 @@ public abstract class AbstractQueue
public int compareTo(final AMQQueue o)
{
- return _name.compareTo(o.getName());
+ return getName().compareTo(o.getName());
}
public AtomicInteger getAtomicQueueCount()
{noformat}
I said beforehand that I wasn't a fan of accessing the attribute fields, and
I'm still not hehe. On that subject though...
- 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.
- 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.
- We possibly shouldn't return null in the event it doesn't find a match, just
to avoid issues going unnoticed for longer.
> [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: Robbie Gemmell
> 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]
