beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers" <>
Subject Re: apt validation annotations incorrect order
Date Fri, 18 Jan 2008 22:08:59 GMT
What version of Beehive do you have? Also what platform/version of APT
are you running?

There was a bug logged and fixed for this issue a while back. See,

This fix should be in Beehive v1.0.2. If you are compiling with
Eclipse and your validation annotations are on the properties in your
form bean class, you may still see an issue. There is a difference
between the Sun and Eclipse APT implementations and the order of the
validation rules declared on the properties (getter methods) of a form

The root cause of the issue is that in the Beehive AP we call the
getMethods() method on a delegate ClassDeclaration. The getMethods()
method returns a Collection. There's no guarantee about the order of
the methods. Sun's
returns the methods in the order that they are declared in the file.
However, with the Eclipse version of the APT,
returns them in alphabetical order.

There's been some discussion about using using getPosition() on the
method declaration, however, the annotation processing interface, new
to Java 6, doesn't seem to have any equivalent to SourcePosition.

If you are using Eclipse with Beehive, then I guess the workaround
would be to define the validatable property declarations in either the
@Jpf.Controller or an @Jpf.Action annotation and the order of the
declarative validation will be preserved.

Kind regards,

On 1/18/08, christopher snow <> wrote:
> The generated pageflow-validations-X.xml file generated from my
> controller does not create the validation rules in the same order that
> the annotations were defined in the controller.   This means that errors
> displayed with <netui:errors/> is not displayed in the correct order.
> How do I overcome this?
> Thanks in advance...
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

View raw message