[bv-dev] Should getters be considered methods during validation

Emmanuel Bernard emmanuel at hibernate.org
Mon Dec 17 12:42:31 EST 2012


OK, we have had experience with packaged annotations for both Hibernate
Search and Hibernate ORM and I have personally not seen people confused by
them.

I am a bit uneasy about offering an XML only feature (or an annotation
only feature for what it is worth). So we would go for an all or nothing
here. Hardy and I feel that package annotations are the natural
solution to the problem but if people feel uneasy about them, we can
offer them as a provider extension only.

About CDI, I don't know the exact reason for them to drop package
annotations but I know a few reasons why it would be inconvenient for them.
CDI does scanning and that creates a significant performance bottleneck as class
loading is dead slow in Java. So forcing CDI impl to load all classes
within a package can be seen as costly though I have had discussions with
the JBoss AS 7 lead and Pete from CDI about how that would not be that
bad.

In our case however, we don't need any scanning, we simply need to load
the package-info of the package a given constrained method bean is in to
find the expected behavior. Such lookup is unlikely to make any
significant performance difference.

Emmanuel

On Sat 2012-12-15  0:12, Gerhard Petracek wrote:
> if everything is fine in an application, you won't see issues with package
> annotations.
> 
> that users aren't used to it is an important part, because package
> annotations are quite hidden and usually unexpected.
> esp. because they are quite unexpected, it can happen pretty easily e.g.
> during a refactoring/cleanup/... that the application behaves differently
> afterwards, but you don't recognize it immediately and later on most people
> just check the history of config file/s (and not the package-info).
> 
> @ "... the first version found ...":
> yes - the behaviour you described is correct, but that's imo even worse.
> such issues are sometimes hard enough with classes (e.g. there are
> ee-servers which behave differently depending on the names of the archives
> -> something can work in application x and in application y there is the
> same setup but it fails due to different archive-names). since such issues
> are around for years a lot of people know about them, but imo issues caused
> by package annotations are harder to find, because package annotations are
> just unexpected and it's hard(er) to find the meta-data if it's e.g. a
> leftover in a different jar than the one you are looking at.
> 
> fyi: mark just told me that the cdi-eg dropped package annotations as well.
> 
> regards,
> gerhard
> 
> 
> 
> 2012/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> 
> > Having multiple definitions of package annotations for a given package
> > (via split packages) is equivalent to having the same class name used twice
> > in a split package. The first version found in your class path is the one
> > used by the VM.
> > I don't think we should use a different rule. And to me the same class
> > define twice is of the same level of error as a package-info.java defined
> > twice for the same package.
> >
> > On 13 déc. 2012, at 16:40, Matt Benson <mbenson at apache.org> wrote:
> >
> > I think folk not being used to package annotations was a big part of
> > Gerhard's objections, but what I personally find more problematic is the
> > fact that multiple jars could conceivably include annotations for the same
> > package.  We might respond to that with a rule that a package annotation is
> > only applied to the archive in which it is found, but then, AFAICT, an
> > implementor would have to resort to bytecode analysis in order to sort out
> > which setting applies to which jar.  That could be more cleanly done by
> > using a resource-based mechanism for package configs per containing jar,
> > but then we're left with the IMO somewhat ugly situation of disparate
> > mechanisms for package config vs. everything else.
> >
> > Matt
> >
> >
> > On Thu, Dec 13, 2012 at 3:28 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> >
> >> On Wed 2012-12-12 21:02, Gerhard Petracek wrote:
> >> > i had a nice discussion with matt.
> >> > since bv 1.0 only supports one validation.xml, i'm ok with a package
> >> config
> >> > in validation.xml.
> >> > however, package annotations are in most cases just unexpected (and
> >> > error-prone).
> >> > (e.g. in deltaspike we dropped such annotations because of that.)
> >>
> >> I am curious about that. What makes you say that? What made them
> >> error-prone for Deltaspike?
> >> You mean unexpected because people are not used to them?
> >>
> >> Emmanuel
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >

> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



More information about the beanvalidation-dev mailing list