(From the issue) Clearly, Region names are supposed to be described using String-only FQNs. This is because Regions are configured using String names in their configuration. Also, the file and JDBC based persistence system do not handle non-String FQNs. But here are several use cases for using non-String FQN. For example, at my past company, we stored mobile handset data by country code and phone numbers as numbers. Things like integers and enumerated types are obviously more lightweight than string objects as keys. Personally, I think that being able to use appropriate types in the FQN is worthwhile efficiency and is more consistent with the Java philosophy of type safety. In any case, it would be nice to have an audit of areas that: 0. Do support non-String FQN by design. 1. Do not support non-String FQN, but possibly could (create new issues for these?). 2. Cannot support non-String FQN, and are not documented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983888#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...