You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Brad Cupit (JIRA)" <ji...@apache.org> on 2008/04/04 16:57:59 UTC

[jira] Created: (WW-2577) @Result annotation could use the compiler to enforce strong restriction

@Result annotation could use the compiler to enforce strong restriction
-----------------------------------------------------------------------

                 Key: WW-2577
                 URL: https://issues.apache.org/struts/browse/WW-2577
             Project: Struts 2
          Issue Type: Improvement
          Components: Core Actions
            Reporter: Brad Cupit
            Priority: Trivial


Note: this would be extremely easy to fix

The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.

1) Add @Target(ElementType.TYPE)
the documentation says not to put the annotation on methods, as it only works on classes. This update makes it a compile error if the action is put on anything other than a class

2) make type() a Class<? extends Result>
the type() field is of type Class, but by making it of type Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in the first option, however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.

The final code would look like this:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Result {
	String name() default Action.SUCCESS;
	Class<? extends Result> type() default NullResult.class;
	String value();
	String[] params() default {};
}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (WW-2577) @Result annotation - use the compiler to enforce stronger restrictions

Posted by "Brad Cupit (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/struts/browse/WW-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43712#action_43712 ] 

Brad Cupit commented on WW-2577:
--------------------------------

Very cool! thanks for the fix!

I didn't realize until I looked at the source in trunk that you'd have to use the fully qualified class name in the Class<? extends Result> but it makes perfect sense. My fault.

Thanks for adding the code Don!

> @Result annotation - use the compiler to enforce stronger restrictions
> ----------------------------------------------------------------------
>
>                 Key: WW-2577
>                 URL: https://issues.apache.org/struts/browse/WW-2577
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Actions
>            Reporter: Brad Cupit
>            Assignee: Don Brown
>            Priority: Trivial
>             Fix For: 2.1.2
>
>
> Note: this would be extremely easy to fix
> The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.
> 1) Add @Target(ElementType.TYPE)
> the documentation says not to put the Result annotation on methods, since it only works on classes. Adding the Target annotation to the Result annotation would make it a compiler error if the Result annotation is put on anything other than a class
> 2) make type() a Class<? extends Result>
> the type() field is a Class, but by making it a Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in 1), however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.
> The final code would look like this:
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Result {
> 	String name() default Action.SUCCESS;
> 	Class<? extends Result> type() default NullResult.class;
> 	String value();
> 	String[] params() default {};
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (WW-2577) @Result annotation - use the compiler to enforce stronger restrictions

Posted by "Brad Cupit (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Cupit closed WW-2577.
--------------------------


looks correct in the code in trunk

> @Result annotation - use the compiler to enforce stronger restrictions
> ----------------------------------------------------------------------
>
>                 Key: WW-2577
>                 URL: https://issues.apache.org/struts/browse/WW-2577
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Actions
>            Reporter: Brad Cupit
>            Assignee: Don Brown
>            Priority: Trivial
>             Fix For: 2.1.2
>
>
> Note: this would be extremely easy to fix
> The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.
> 1) Add @Target(ElementType.TYPE)
> the documentation says not to put the Result annotation on methods, since it only works on classes. Adding the Target annotation to the Result annotation would make it a compiler error if the Result annotation is put on anything other than a class
> 2) make type() a Class<? extends Result>
> the type() field is a Class, but by making it a Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in 1), however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.
> The final code would look like this:
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Result {
> 	String name() default Action.SUCCESS;
> 	Class<? extends Result> type() default NullResult.class;
> 	String value();
> 	String[] params() default {};
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Issue Comment Edited: (WW-2577) @Result annotation - use the compiler to enforce stronger restrictions

Posted by "Brad Cupit (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/struts/browse/WW-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43712#action_43712 ] 

bradcupit edited comment on WW-2577 at 4/21/08 6:32 AM:
---------------------------------------------------------

Very cool! thanks for the fix!

I didn't realize until I looked at the source in trunk that you'd have to use the fully qualified class name in the Class<? extends Result> but it makes sense. My fault.

Thanks for adding the code Don!

      was (Author: bradcupit):
    Very cool! thanks for the fix!

I didn't realize until I looked at the source in trunk that you'd have to use the fully qualified class name in the Class<? extends Result> but it makes perfect sense. My fault.

Thanks for adding the code Don!
  
> @Result annotation - use the compiler to enforce stronger restrictions
> ----------------------------------------------------------------------
>
>                 Key: WW-2577
>                 URL: https://issues.apache.org/struts/browse/WW-2577
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Actions
>            Reporter: Brad Cupit
>            Assignee: Don Brown
>            Priority: Trivial
>             Fix For: 2.1.2
>
>
> Note: this would be extremely easy to fix
> The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.
> 1) Add @Target(ElementType.TYPE)
> the documentation says not to put the Result annotation on methods, since it only works on classes. Adding the Target annotation to the Result annotation would make it a compiler error if the Result annotation is put on anything other than a class
> 2) make type() a Class<? extends Result>
> the type() field is a Class, but by making it a Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in 1), however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.
> The final code would look like this:
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Result {
> 	String name() default Action.SUCCESS;
> 	Class<? extends Result> type() default NullResult.class;
> 	String value();
> 	String[] params() default {};
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (WW-2577) @Result annotation - use the compiler to enforce stronger restrictions

Posted by "Don Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Don Brown resolved WW-2577.
---------------------------

       Resolution: Fixed
    Fix Version/s: 2.1.2
         Assignee: Don Brown

Great idea, thanks for the patch.

> @Result annotation - use the compiler to enforce stronger restrictions
> ----------------------------------------------------------------------
>
>                 Key: WW-2577
>                 URL: https://issues.apache.org/struts/browse/WW-2577
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Actions
>            Reporter: Brad Cupit
>            Assignee: Don Brown
>            Priority: Trivial
>             Fix For: 2.1.2
>
>
> Note: this would be extremely easy to fix
> The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.
> 1) Add @Target(ElementType.TYPE)
> the documentation says not to put the Result annotation on methods, since it only works on classes. Adding the Target annotation to the Result annotation would make it a compiler error if the Result annotation is put on anything other than a class
> 2) make type() a Class<? extends Result>
> the type() field is a Class, but by making it a Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in 1), however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.
> The final code would look like this:
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Result {
> 	String name() default Action.SUCCESS;
> 	Class<? extends Result> type() default NullResult.class;
> 	String value();
> 	String[] params() default {};
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WW-2577) @Result annotation - use the compiler to enforce stronger restrictions

Posted by "Brad Cupit (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Cupit updated WW-2577:
---------------------------

    Description: 
Note: this would be extremely easy to fix

The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.

1) Add @Target(ElementType.TYPE)
the documentation says not to put the Result annotation on methods, since it only works on classes. Adding the Target annotation to the Result annotation would make it a compiler error if the Result annotation is put on anything other than a class

2) make type() a Class<? extends Result>
the type() field is a Class, but by making it a Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in 1), however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.

The final code would look like this:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Result {
	String name() default Action.SUCCESS;
	Class<? extends Result> type() default NullResult.class;
	String value();
	String[] params() default {};
}

  was:
Note: this would be extremely easy to fix

The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.

1) Add @Target(ElementType.TYPE)
the documentation says not to put the annotation on methods, as it only works on classes. This update makes it a compile error if the action is put on anything other than a class

2) make type() a Class<? extends Result>
the type() field is of type Class, but by making it of type Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in the first option, however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.

The final code would look like this:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Result {
	String name() default Action.SUCCESS;
	Class<? extends Result> type() default NullResult.class;
	String value();
	String[] params() default {};
}

        Summary: @Result annotation - use the compiler to enforce stronger restrictions  (was: @Result annotation could use the compiler to enforce strong restriction)

> @Result annotation - use the compiler to enforce stronger restrictions
> ----------------------------------------------------------------------
>
>                 Key: WW-2577
>                 URL: https://issues.apache.org/struts/browse/WW-2577
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Actions
>            Reporter: Brad Cupit
>            Priority: Trivial
>
> Note: this would be extremely easy to fix
> The @Result annotation could have more restrictions that use the compiler to enforce certain behaviors.
> 1) Add @Target(ElementType.TYPE)
> the documentation says not to put the Result annotation on methods, since it only works on classes. Adding the Target annotation to the Result annotation would make it a compiler error if the Result annotation is put on anything other than a class
> 2) make type() a Class<? extends Result>
> the type() field is a Class, but by making it a Class<? extends Result> it enforces that the type implement the Result interface. The advantage here is much weaker than in 1), however it would self-document the code so anyone writing a custom 'type' would know to implement the Result interface.
> The final code would look like this:
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Result {
> 	String name() default Action.SUCCESS;
> 	Class<? extends Result> type() default NullResult.class;
> 	String value();
> 	String[] params() default {};
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.