Uploaded image for project: 'Beehive'
  1. Beehive
  2. BEEHIVE-1087

Controls with simple name conflicts not resolved correctly

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.0.1
    • 1.0.2
    • Controls
    • None

    Description

      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.

      Attachments

        1. wrong_control_selected.zip
          2 kB
          Jess Garms

        Activity

          People

            Unassigned Unassigned
            jgarms Jess Garms
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: