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(a)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(a)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(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev