You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "Jess Garms (JIRA)" <de...@beehive.apache.org> on 2006/03/31 02:35:27 UTC
[jira] Created: (BEEHIVE-1087) Controls with simple name conflicts
not resolved correctly
Controls with simple name conflicts not resolved correctly
----------------------------------------------------------
Key: BEEHIVE-1087
URL: http://issues.apache.org/jira/browse/BEEHIVE-1087
Project: Beehive
Type: Bug
Components: Controls
Versions: 1.0.1
Reporter: Jess Garms
I have two controls, both called FooControl, in separate packages. If I then refer to one of them via their generated Bean class in a Controller, the annotation processor doesn't always use the correct one. I'll attach source code that exhibits this problem, where a reference to b.FooControlBean becomes a reference to a.FooControlBean in the generated code.
This occurs because during a clean build the generated Bean class has not yet been generated, so the annotation processor searches for all types that are annotated with @ControlInterface, and looks for one with a matching simple name, ignoring the package. In this case, there are two such types with matching simple names in different packages, and the annotation processor cannot differentiate between the two, as APT provides no means for examining imports or resolving the fully-qualified name of a type that has not been generated (in this case the Bean).
A possible fix: add an optional value to the Control annotation like so:
public @interface Control {
Class<?> interfaceClass default Object.class;
}
Then if @Control is used on a generated Bean class, the user could indicate what the interface is (from the example I'll be attaching):
...
import b.*;
...
@Control(FooControl.class)
private FooControlBean fooControl;
...
This change is binary- and source-compatible with previous releases, as the new value is optional.
When processing the use of the control, the annotation processor could use the interfaceClass value to determine which interface to use for the Bean instance.
--
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] Closed: (BEEHIVE-1087) Controls with simple name conflicts
not resolved correctly
Posted by "Alejandro Ramirez (JIRA)" <de...@beehive.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-1087?page=all ]
Alejandro Ramirez closed BEEHIVE-1087.
--------------------------------------
Assignee: (was: Jacob Danner)
> Controls with simple name conflicts not resolved correctly
> ----------------------------------------------------------
>
> Key: BEEHIVE-1087
> URL: http://issues.apache.org/jira/browse/BEEHIVE-1087
> Project: Beehive
> Issue Type: Bug
> Components: Controls
> Affects Versions: 1.0.1
> Reporter: Jess Garms
> Fix For: v.next
>
> Attachments: wrong_control_selected.zip
>
>
> I have two controls, both called FooControl, in separate packages. If I then refer to one of them via their generated Bean class in a Controller, the annotation processor doesn't always use the correct one. I'll attach source code that exhibits this problem, where a reference to b.FooControlBean becomes a reference to a.FooControlBean in the generated code.
> This occurs because during a clean build the generated Bean class has not yet been generated, so the annotation processor searches for all types that are annotated with @ControlInterface, and looks for one with a matching simple name, ignoring the package. In this case, there are two such types with matching simple names in different packages, and the annotation processor cannot differentiate between the two, as APT provides no means for examining imports or resolving the fully-qualified name of a type that has not been generated (in this case the Bean).
> A possible fix: add an optional value to the Control annotation like so:
> public @interface Control {
> Class<?> interfaceClass default Object.class;
> }
> Then if @Control is used on a generated Bean class, the user could indicate what the interface is (from the example I'll be attaching):
> ...
> import b.*;
> ...
> @Control(FooControl.class)
> private FooControlBean fooControl;
> ...
> This change is binary- and source-compatible with previous releases, as the new value is optional.
> When processing the use of the control, the annotation processor could use the interfaceClass value to determine which interface to use for the Bean instance.
--
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] Updated: (BEEHIVE-1087) Controls with simple name conflicts
not resolved correctly
Posted by "Jess Garms (JIRA)" <de...@beehive.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-1087?page=all ]
Jess Garms updated BEEHIVE-1087:
--------------------------------
Attachment: wrong_control_selected.zip
> Controls with simple name conflicts not resolved correctly
> ----------------------------------------------------------
>
> Key: BEEHIVE-1087
> URL: http://issues.apache.org/jira/browse/BEEHIVE-1087
> Project: Beehive
> Type: Bug
> Components: Controls
> Versions: 1.0.1
> Reporter: Jess Garms
> Attachments: wrong_control_selected.zip
>
> I have two controls, both called FooControl, in separate packages. If I then refer to one of them via their generated Bean class in a Controller, the annotation processor doesn't always use the correct one. I'll attach source code that exhibits this problem, where a reference to b.FooControlBean becomes a reference to a.FooControlBean in the generated code.
> This occurs because during a clean build the generated Bean class has not yet been generated, so the annotation processor searches for all types that are annotated with @ControlInterface, and looks for one with a matching simple name, ignoring the package. In this case, there are two such types with matching simple names in different packages, and the annotation processor cannot differentiate between the two, as APT provides no means for examining imports or resolving the fully-qualified name of a type that has not been generated (in this case the Bean).
> A possible fix: add an optional value to the Control annotation like so:
> public @interface Control {
> Class<?> interfaceClass default Object.class;
> }
> Then if @Control is used on a generated Bean class, the user could indicate what the interface is (from the example I'll be attaching):
> ...
> import b.*;
> ...
> @Control(FooControl.class)
> private FooControlBean fooControl;
> ...
> This change is binary- and source-compatible with previous releases, as the new value is optional.
> When processing the use of the control, the annotation processor could use the interfaceClass value to determine which interface to use for the Bean instance.
--
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-1087) Controls with simple name conflicts
not resolved correctly
Posted by "Chad Schoettger (JIRA)" <de...@beehive.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-1087?page=all ]
Chad Schoettger resolved BEEHIVE-1087:
--------------------------------------
Fix Version: v.next
Resolution: Fixed
Assign To: Alejandro Ramirez (was: Chad Schoettger)
Modified org.apache.beehive.controls.api.bean.Control annotation to include an optional interface hint attribute:
public @interface Control
{
/**
* Optional member used to specify the control interface class.
* Typically only necessary to resolve ambiguities when multiple
* control interfaces with same name but different packages are present.
*/
Class<?> interfaceHint() default Object.class;
}
The interfaceHint may be used to explicitly specify the control's interface class.
> Controls with simple name conflicts not resolved correctly
> ----------------------------------------------------------
>
> Key: BEEHIVE-1087
> URL: http://issues.apache.org/jira/browse/BEEHIVE-1087
> Project: Beehive
> Type: Bug
> Components: Controls
> Versions: 1.0.1
> Reporter: Jess Garms
> Assignee: Alejandro Ramirez
> Fix For: v.next
> Attachments: wrong_control_selected.zip
>
> I have two controls, both called FooControl, in separate packages. If I then refer to one of them via their generated Bean class in a Controller, the annotation processor doesn't always use the correct one. I'll attach source code that exhibits this problem, where a reference to b.FooControlBean becomes a reference to a.FooControlBean in the generated code.
> This occurs because during a clean build the generated Bean class has not yet been generated, so the annotation processor searches for all types that are annotated with @ControlInterface, and looks for one with a matching simple name, ignoring the package. In this case, there are two such types with matching simple names in different packages, and the annotation processor cannot differentiate between the two, as APT provides no means for examining imports or resolving the fully-qualified name of a type that has not been generated (in this case the Bean).
> A possible fix: add an optional value to the Control annotation like so:
> public @interface Control {
> Class<?> interfaceClass default Object.class;
> }
> Then if @Control is used on a generated Bean class, the user could indicate what the interface is (from the example I'll be attaching):
> ...
> import b.*;
> ...
> @Control(FooControl.class)
> private FooControlBean fooControl;
> ...
> This change is binary- and source-compatible with previous releases, as the new value is optional.
> When processing the use of the control, the annotation processor could use the interfaceClass value to determine which interface to use for the Bean instance.
--
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-1087) Controls with simple name
conflicts not resolved correctly
Posted by "Russ Baker (JIRA)" <de...@beehive.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-1087?page=comments#action_12423357 ]
Russ Baker commented on BEEHIVE-1087:
-------------------------------------
I recommend that this bug be closed. I have verified the fix by using the "wrong_control_selected.zip" file. I wrote a JUnit test to use the control insted of using Controller.java for the test. This was tested against SVN#425410.
> Controls with simple name conflicts not resolved correctly
> ----------------------------------------------------------
>
> Key: BEEHIVE-1087
> URL: http://issues.apache.org/jira/browse/BEEHIVE-1087
> Project: Beehive
> Issue Type: Bug
> Components: Controls
> Affects Versions: 1.0.1
> Reporter: Jess Garms
> Assigned To: Jacob Danner
> Fix For: v.next
>
> Attachments: wrong_control_selected.zip
>
>
> I have two controls, both called FooControl, in separate packages. If I then refer to one of them via their generated Bean class in a Controller, the annotation processor doesn't always use the correct one. I'll attach source code that exhibits this problem, where a reference to b.FooControlBean becomes a reference to a.FooControlBean in the generated code.
> This occurs because during a clean build the generated Bean class has not yet been generated, so the annotation processor searches for all types that are annotated with @ControlInterface, and looks for one with a matching simple name, ignoring the package. In this case, there are two such types with matching simple names in different packages, and the annotation processor cannot differentiate between the two, as APT provides no means for examining imports or resolving the fully-qualified name of a type that has not been generated (in this case the Bean).
> A possible fix: add an optional value to the Control annotation like so:
> public @interface Control {
> Class<?> interfaceClass default Object.class;
> }
> Then if @Control is used on a generated Bean class, the user could indicate what the interface is (from the example I'll be attaching):
> ...
> import b.*;
> ...
> @Control(FooControl.class)
> private FooControlBean fooControl;
> ...
> This change is binary- and source-compatible with previous releases, as the new value is optional.
> When processing the use of the control, the annotation processor could use the interfaceClass value to determine which interface to use for the Bean instance.
--
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] Assigned: (BEEHIVE-1087) Controls with simple name conflicts
not resolved correctly
Posted by "Chad Schoettger (JIRA)" <de...@beehive.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-1087?page=all ]
Chad Schoettger reassigned BEEHIVE-1087:
----------------------------------------
Assign To: Chad Schoettger
> Controls with simple name conflicts not resolved correctly
> ----------------------------------------------------------
>
> Key: BEEHIVE-1087
> URL: http://issues.apache.org/jira/browse/BEEHIVE-1087
> Project: Beehive
> Type: Bug
> Components: Controls
> Versions: 1.0.1
> Reporter: Jess Garms
> Assignee: Chad Schoettger
> Attachments: wrong_control_selected.zip
>
> I have two controls, both called FooControl, in separate packages. If I then refer to one of them via their generated Bean class in a Controller, the annotation processor doesn't always use the correct one. I'll attach source code that exhibits this problem, where a reference to b.FooControlBean becomes a reference to a.FooControlBean in the generated code.
> This occurs because during a clean build the generated Bean class has not yet been generated, so the annotation processor searches for all types that are annotated with @ControlInterface, and looks for one with a matching simple name, ignoring the package. In this case, there are two such types with matching simple names in different packages, and the annotation processor cannot differentiate between the two, as APT provides no means for examining imports or resolving the fully-qualified name of a type that has not been generated (in this case the Bean).
> A possible fix: add an optional value to the Control annotation like so:
> public @interface Control {
> Class<?> interfaceClass default Object.class;
> }
> Then if @Control is used on a generated Bean class, the user could indicate what the interface is (from the example I'll be attaching):
> ...
> import b.*;
> ...
> @Control(FooControl.class)
> private FooControlBean fooControl;
> ...
> This change is binary- and source-compatible with previous releases, as the new value is optional.
> When processing the use of the control, the annotation processor could use the interfaceClass value to determine which interface to use for the Bean instance.
--
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