qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-5591) [Java Broker] Move responsibility for setting attribute values to AbstractConfiguredObject
Date Tue, 04 Mar 2014 13:10:25 GMT

    [ 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message