[ http://issues.apache.org/jira/browse/BEEHIVE-357?page=comments#action_12319118 ]
Jacob Danner commented on BEEHIVE-357: -------------------------------------- Looks like this issue should get some closure. > Limit type of annotations that can be externally overriden > ---------------------------------------------------------- > > Key: BEEHIVE-357 > URL: http://issues.apache.org/jira/browse/BEEHIVE-357 > Project: Beehive > Type: Improvement > Components: Controls > Versions: V1Alpha > Reporter: David Read > Assignee: Kyle Marvin > Priority: Minor > Fix For: v1m1 > > JSR175 constrains the set of Java types that can exist as members (methods > return type) on an annotation. Some of those types don't really make sense > for external configuration (e.g. Class or byte and arrays of Class or byte). > There's also a practical matter of allowing arrays of primitive types and > nested annotations. In those cases, the structural representation and any > tooling should probably be in sync to make it easy to visualize what's being > configured relative to the structure of the application. There's also the > complexity of defining what it means to change an array? The simplest model > would probably be a full replacement of the array, rather than specifying > "changes". > For v1, we should consider limiting annotations that can be overriden > externally to those than contain only simple primitive types (e.g. String, > int, float, boolean ... no arrays, no nesting). The annotation processor for > controls would have to enforce this so the user wouldn't see a downstream > build error that could have been caught sooner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
