Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Message-ID: <1547177903.1143765453174.JavaMail.jira@ajax>
Date: Fri, 31 Mar 2006 01:37:33 +0100 (BST)
From: "Jess Garms (JIRA)" <dev@beehive.apache.org>
To: dev@beehive.apache.org
Subject: [jira] Updated: (BEEHIVE-1087) Controls with simple name conflicts
 not resolved correctly
In-Reply-To: <753066655.1143765327240.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ 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