[hibernate-dev] [BV] Validation.byProvider() revisited

[Emmanuel Bernard]

Hardy,
Wish #1 realized. But this has consequences:
  - I broke the TCK test suite :)
  - you are officially responsible to review the spec / javadoc  
changes (see attached email with spec diff)

Begin forwarded message:

> From: Emmanuel Bernard <emmanuel.bernard at JBOSS.COM>
> Date:  June 15, 2009 23:10:33  EDT
> To: JSR-303-EG at JCP.ORG
> Subject: Validation.byProvider() revisited
> Reply-To: Java Community Process JSR #303 Expert List <JSR-303-EG at JCP.ORG 
> >
>
> I never liked the idea that byProvider() was taking a Configuration  
> subclass and not the actual ValidationProvider class.
> This is now fixed using some additional generics magic. It has also  
> the nice side effect of simplifying the contract between the  
> bootstrap module and the providers.
>
> In a nutshell, instead of
>
> ValidatorFactory factory = Validation
>        .byProvider( ACMEConfiguration.class )  //chose a specific  
> provider
>        .configure()
>           .messageInterpolator( new  
> ContainerMessageInterpolator() ) //default configuration option
>           .addConstraint(Address.class,  
> customConstraintDescriptor) //ACME specific method
>           .buildValidatorFactory();
>
> we have
>
> ValidatorFactory factory = Validation
>        .byProvider( ACMEProvider.class )  //chose a specific provider
>        .configure()
>           .messageInterpolator( new  
> ContainerMessageInterpolator() ) //default configuration option
>           .addConstraint(Address.class,  
> customConstraintDescriptor) //ACME specific method
>           .buildValidatorFactory();
>
> The ACME provider becomes
>
> /**
>  * ACME validation provider
>  * Note how ACMEConfiguration and ACMEProvider are linked together
>  * via the generic parameter.
>  */
> public class ACMEProvider implements  
> ValidationProvider<ACMEConfiguration> {
>     ...
> }
>
>
> Validation.byProvider() now is
>
> /**
> 	 * Build a <code>Configuration</code> for a particular provider  
> implementation.
> 	 * Optionally overrides the provider resolution strategy used to  
> determine the provider.
> 	 * <p/>
> 	 * Used by applications targeting a specific provider  
> programmatically.
> 	 * <p/>
> 	 * <pre>
> 	 * ACMEConfiguration configuration =
> 	 *     Validation.byProvider(ACMEProvider.class)
> 	 *             .providerResolver( new MyResolverStrategy() )
> 	 *             .configure();
> 	 * </pre>,
> 	 * where <code>ACMEConfiguration</code> is the
> 	 * <code>Configuration</code> sub interface uniquely identifying the
> 	 * ACME Bean Validation provider. and ACMEProvider is the  
> ValidationProvider
> 	 * implementation of the ACME provider.
> 	 *
> 	 * @param providerType the <code>ValidationProvider</code>  
> implementation type
> 	 *
> 	 * @return instance building a provider specific  
> <code>Configuration</code>
> 	 * sub interface implementation.
> 	 */
> 	public static <T extends Configuration<T>, U extends  
> ValidationProvider<T>>
> 			ProviderSpecificBootstrap<T> byProvider(Class<U> providerType) {
> 		[...]
> 	}
>
> ValidationProvider now is
>
> package javax.validation.spi;
>
> /**
>  * Contract between the validation bootstrap mechanism and the  
> provider engine.
>  * <p/>
>  * Implementations must have a public no-arg constructor. The  
> construction of a provider
>  * should be as "lightweight" as possible.
>  *
>  * <code>T</code> represents the provider specific Configuration  
> subclass
>  * which typically host provider's additional configuration methods.
>  *
>  * @author Emmanuel Bernard
>  * @author Hardy Ferentschik
>  */
> public interface ValidationProvider<T extends Configuration<T>> {
>
> 	/**
> 	 * Returns a Configuration instance implementing <code>T</code>,
> 	 * the <code>Configuration</code> subinterface.
> 	 * The returned Configuration instance must use the current  
> provider (<code>this</code>)
> 	 * to build the ValidatorFactory instance.
> 	 * <p/>
> 	 *
> 	 * @param state bootstrap state
> 	 *
> 	 * @return specific Configuration implementation
> 	 */
> 	T createSpecializedConfiguration(BootstrapState state);
>
> 	/**
> 	 * Returns a Configuration instance. This instance is not bound to
> 	 * use the current provider. The choice of provider follows the  
> algorithm described
> 	 * in {@link javax.validation.Configuration}
> 	 * <p/>
> 	 * The ValidationProviderResolver used by <code>Configuration</code>
> 	 * is provided by <code>state</code>.
> 	 * If null, the default ValidationProviderResolver is used.
> 	 *
> 	 * @param state bootstrap state
> 	 *
> 	 * @return Non specialized Configuration implementation
> 	 */
> 	Configuration<?> createGenericConfiguration(BootstrapState state);
>
> 	/**
> 	 * Build a ValidatorFactory using the current provider  
> implementation. The
> 	 * ValidatorFactory is assembled and follows the configuration passed
> 	 * via ConfigurationState.
> 	 * <p>
> 	 * The returned ValidatorFactory is properly initialized and ready  
> for use.
> 	 * </p>
> 	 *
> 	 * @param configurationState the configuration descriptor
> 	 *
> 	 * @return the instanciated ValidatorFactory
> 	 * @throws javax.validation.ValidationException if the  
> ValidatorFactory cannot be built
> 	 */
> 	ValidatorFactory buildValidatorFactory(ConfigurationState  
> configurationState);
> }
>
> esp, we no longer have isSuitable.
>
>
> Any objection? The diff for the spec is attached
> http://people.redhat.com/~ebernard/validation/#bootstrapping
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090615/65878e5d/attachment.html 
-------------- next part --------------
An embedded message was scrubbed...
From: ebernard at redhat.com
Subject: Beancheck SVN:  r227 - spec/trunk/specbook/en.
Date: Mon, 15 Jun 2009 22:57:07 -0400
Size: 42131
Url: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090615/65878e5d/attachment.eml 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090615/65878e5d/attachment-0001.html