I would recommend you allow your user to be a "real" Bean Validation consumer and force them to bootstrap it in a normal way. You can't predict what other technologies they'll be using in conjunction with Struts 2, so why try? If you can write your plugin such that it can either be configured with a ValidatorFactory instance or obtain one using javax.validation.Validation.buildDefaultValidatorFactory(), then you would seem to be covered, and you haven't insulated your user from the responsbility/opportunity of learning how to set up BV metadata in whatever manner makes sense for his particular scenario, including making his preferred implementation available. If, for example, the user is running in a Java EE 6 or Java EE 6 Web Profile container, he would already have some Bean Validation implementation available. Otherwise, he'll have to choose, but that's better IMO than your plugin providing things that may not be needed, or worse, potentially causing unanticipated issues by having, e.g., multiple versions of Apache BVal on the classpath.
Matt On Tue, Oct 15, 2013 at 12:15 PM, Umesh Awasthi <[email protected]>wrote: > Hi Matt, > > Thanks for your inputs and agree with you, i do not want to bind my > implementation with specific implementation. > not sure if i am able to understand second part of your question > completely. > I am trying to provide a bridge between Struts2 and Bean validation > API.While user submit there inputs, i am putting them through Validation > using BV and if any kind of exception occurring, using Struts2 message API > to read error messages and display them to UI. > > Through this , idea is to let use specify which bean validation they want > to use be it > 1. Apache Bean validation > 2. Hibernate Validator. > > I have plan to put Apache Bean Validation as Default validator in case use > do not specify any preferences and want to use out of box functionality. > > Validation.byProvider(this.providerClass).configure().buildValidatorFactory(); > > > where provide class can be configured by user or in case no value is > specified by user, Apache BV will be picked as default implementation. > > Thanks > Umesh > > > > On Tue, Oct 15, 2013 at 10:34 PM, Matt Benson <[email protected]>wrote: > >> ApacheValidatorConfiguration.Properties.VALIDATION_XML_PATH allows you to >> override the location of validation.xml in a manner that is specific to >> Apache BVal, but if you are creating some kind of plugin I'd hardly think >> you'd want to tie yourself to a specific implementation of the Bean >> Validation specification. What specific pattern of use are you trying to >> support for the hypothetical plugin user? >> >> Matt >> >> >> On Tue, Oct 15, 2013 at 11:48 AM, Umesh Awasthi >> <[email protected]>wrote: >> >>> I am trying to test bean validation for my plugin using XML based >>> configuration and while doing i found that i need to place validation/xml >>> file under >>> >>> META-INF/validation.xml inside my resource folder. >>> For me this seems a little strange and who so ever want to use plugin >>> needs to create META-INF folder inside resource folder. >>> >>> I am not sure, if my understanding is correct here and in case i am >>> right, is there any specific reason to choose XML location like this? or >>> can we customize this location >>> >>> -- >>> With Regards >>> Umesh Awasthi >>> http://www.travellingrants.com/ >>> >>> >>> >> >> > > > -- > With Regards > Umesh Awasthi > http://www.travellingrants.com/ > > >
