You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "David Read (JIRA)" <be...@incubator.apache.org> on 2005/02/24 20:55:48 UTC
[jira] Created: (BEEHIVE-357) Limit type of annotations that can be externally overriden
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
Assigned to: Mike Foster
Priority: Minor
Fix For: V1
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (BEEHIVE-357) Limit type of annotations that can be externally overriden
Posted by "Eddie O'Neil (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-357?page=all ]
Eddie O'Neil closed BEEHIVE-357:
--------------------------------
As per Jacob, applying 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
[jira] Commented: (BEEHIVE-357) Limit type of annotations that can be externally overriden
Posted by "Jacob Danner (JIRA)" <be...@incubator.apache.org>.
[ 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
[jira] Resolved: (BEEHIVE-357) Limit type of annotations that can be externally overriden
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-357?page=all ]
Kyle Marvin resolved BEEHIVE-357:
---------------------------------
Resolution: Won't Fix
I'm going to flag this as a "Won't Fix". I think constraining the externally configurable properties to a subset of the valid JSR-175 @interface member types is the wrong thing to do.
The reason I says this is that (by default) PropertySet members are externally configurable, which effectively means you'd be limiting the default behavior. To work around this, users would have to explicitly configure something as not being externally configurable to use arrays, Classes, enumerations, and other fairly basic (and common) property types.
I think the right goal is that *any* Beehive external config mechanism should define and support a config syntax that is in 100% alignment with the scope of valid JSR-175 member types. On the 'array' issue, I think the answer is that external config is always an override/replacement, never a merge, which makes the semantics and behavior pretty clear and understandable, and also easier to implement.
The reality is that some external config mechanisms (in v1) may only be able to support a subset of valid property types, but this restriction should be documented and enforced by file validators associated with that specific config mechanism, not by constraining the base PropertySet declaration mechanism.
David (or others), please speak up if you think I'm missing something in my analysis...
> 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: V1
>
> 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
[jira] Commented: (BEEHIVE-357) Limit type of annotations that can be externally overriden
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-357?page=comments#action_59741 ]
Kyle Marvin commented on BEEHIVE-357:
-------------------------------------
I generally agree, but would include 'Class' in the list of interesting and useful things to configure externally. Having a configurable binding model for interface->impl actually relies upon this.
> 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: Mike Foster
> Priority: Minor
> Fix For: V1
>
> 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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Assigned: (BEEHIVE-357) Limit type of annotations that can be externally overriden
Posted by "Mike Foster (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-357?page=history ]
Mike Foster reassigned BEEHIVE-357:
-----------------------------------
Assign To: Kyle Marvin (was: Mike Foster)
> 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: V1
>
> 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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira