if you were to write a plugin for, say, JBossAS which could control the embedded Tomcat/JBossWeb Connector ports, an expression set might look like:

resource.type.plugin=JBossAS
resource.type.name.contains=Connector
groupby resource.parent.name
groupby resource.pluginConfiguration[port]

problem is the port value will always be an integer, ensured by configuration property validation rules.  but, when the expression evaluator tries to inspect the value to bind it to the query to create each individual group, it will bomb.  the expression evaluator doesn't know the different between a string and an integer, and so since a string is a superset of integer, attempts to cast bind values to the most specific type first.  for the port, the cast to integer succeeds...but as actually the wrong logic.  instead, we WANT port to be interpreted as a string value, because all properties values are string-i-fied in the database and need to use string comparisons.

there is a comment (several months old now) in ExpressionEvaluator.MultipleQueryIterator.getSingleResultList(String) explaining why i suspected this might blow up, as well as what it would take to fix things properly.