beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Schoettger <>
Subject Re: [PATCH] BEEHIVE-1010 AptControlInterface does not detect errors from a custom control checker
Date Fri, 18 Nov 2005 20:41:57 GMT
I like this approach in addition to not having the change the API it also
doesn't rely on the implementor of the checker to do the right thing on
reporting errors.

It looks like it would be necessary to wrap the
AnnotationProcessorEnvironment since it doesn't appear there is a way to set
a Messenger in the environment. I'll look at this a bit more and see what I
can come up with.

- Chad

On 11/18/05, Kyle Marvin <> wrote:
> I haven't reviewed the patch, but an alternative approach might be to
> wrap the original com.sun.mirror.apt.Messager instance provided by the
> APT environment, and then pass this wrapped instance into the custom
> control checker.
> Since a custom checker should *always* raise user visible warnings or
> errors using the Messager interface, the wrapper Messager instance can
> maintain a count of any errors raised (and then just delegate down to
> the original Messager instance).
> This way, you get accurate error detection for free, without an API
> change or requiring that the checker return the right value to you.
> Hope this helps,
> -- Kyle
> On 11/17/05, Chad Schoettger <> wrote:
> > I just posted a patch for BEEHIVE-1010.
> >
> > Basically the bug was that the AptControlInterface has no way of knowing
> if
> > a custom control checker detected any errors. In order to resolve this
> issue
> > it was necessary to modify the ControlChecker interface's check() method
> to
> > return a boolean value instead of void. The boolean return value is used
> to
> > let the AptControlInterface know if there were any errors found by the
> > checker (denoted by a return value of false).
> >
> > The ControlChecker interface is a public interface which custom checkers
> > must extend. Since the fix for this issue involves changing a public API
> I
> > would like to get input from the dev list from anyone who might be
> concerned
> > about this change or have any ideas for other options to resolve this
> issue.
> >
> > - Thanks,
> > Chad
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message