My initial intention of SPI was to separate classes that are never seen my a user of Bean
Validation. BootstrapState and co are contracts only used between the BV provider and the
bootstrap process or the container integration. On the other hands, j.v.bootstrap is
visible by a user.
In that regards, I would not put ParameterNameProvider in spi. But I feel it would pollute
javax.validation. Let's try and find him a decent subpackage.
BTW what's the use case for a BV user to implement ParameterNameProvider? To configure
it?
+1 on better package descriptions.
Emmanuel
On 25 févr. 2012, at 14:15, Gunnar Morling wrote:
Hi all,
I'm in the process of integrating the method validation proposal into
to the first draft of the spec. document. Thanks again for all
comments and feedback.
While going over the ParameterNameProvider interface I wondered where
this interface should actually live. Should it be
javax.validation.ParameterNameProvider or
javax.validation.spi.ParameterNameProvider? Or put more generally,
what's the intention of the spi package in the BV API?
ParameterNameProvider is intended to be implemented by BV providers,
integrators and clients. According to my understanding of the SPI idea
(separate parts intended to be *implemented* by clients [SPI] from
parts intended to be *used* by clients [API]) therefore I'd say it's a
candidate for the SPI package. But following that reasoning, for
instance also the ConstraintValidator interface should be part of the
spi package, which it isn't in BV 1.0.
Based on the contained classes I'm supposing that the BV spi package
has a much more focused scope (bootstrapping). Then
ParameterNameProvider should go into javax.validation. Any thoughts?
Btw. there isn't much package-level JavaDoc for the BV API in general
(only for javax.validation.groups). I think we should add some more
for BV 1.1. WDYT?
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev