Why can't TomEE rely on BVal for parsing? We should devise something as simple as possible, whatever the case.
Matt On Wed, Mar 19, 2014 at 10:45 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > well this way we'll need another spi for TomEE which can't rely on > BVal for parsing. That's why I thought sending the parsing result > > > BTW any urgence on it? > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-03-19 16:43 GMT+01:00 Matt Benson <mben...@apache.org>: >> I was thinking along the lines Michael says. e.g.: >> >> public interface DefaultValidationConfigurationProvider { >> InputStream getDefaultValidationConfiguration(); >> } >> >> Then we use ServiceLoader (functional equivalent for BVal 1.0, Java 5) >> to find any available implementations. If none found, we fall back to: >> >> class StandardDefaultValidationConfigurationProvider implements >> DefaultValidationConfigurationProvider { >> final Properties properties; >> StandardDefaultValidationConfigurationProvider(Properties properties) { >> this.properties = properties; >> } >> >> public InputStream getDefaultValidationConfiguration() { >> // look for property pointing to custom resource, else >> META-INF/validation.xml >> // ensure only one such resource >> // return getResourceAsStream(resourceName) >> } >> } >> >> This way TomEE would simply have to provide: >> >> WebApplicationDefaultValidationConfigurationProvider implements >> DefaultValidationConfigurationProvider { >> public InputStream getDefaultValidationConfiguration() { >> return getServletContext().getResourceAsStream("WEB-INF/validation.xml"); >> } >> >> private static ServletContext getServletContext() { >> // TBD >> } >> } >> >> Matt >> >> On Wed, Mar 19, 2014 at 10:28 AM, Romain Manni-Bucau >> <rmannibu...@gmail.com> wrote: >>> Actually I'd expect the SPI to give the processed instance and not the >>> location. That's why i sugegsted to wait a bit for it to see the real >>> need. >>> >>> >>> Romain Manni-Bucau >>> Twitter: @rmannibucau >>> Blog: http://rmannibucau.wordpress.com/ >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> Github: https://github.com/rmannibucau >>> >>> >>> >>> 2014-03-19 16:10 GMT+01:00 Michael Blyakher <michael.blyak...@gmail.com>: >>>> How would an SPI like this work? Would it allow the EE server to specify >>>> the location of the validation.xml (maybe in the form of an InputStream)? >>>> >>>> >>>> On Tue, Mar 18, 2014 at 1:59 PM, Romain Manni-Bucau >>>> <rmannibu...@gmail.com>wrote: >>>> >>>>> tomee parses it itself and then create the configuration itself. I >>>>> think we can wait tomee starts javaee7 to write it since it should be >>>>> very soon (when next release is done) and it would be the main and >>>>> more demanding user. >>>>> Romain Manni-Bucau >>>>> Twitter: @rmannibucau >>>>> Blog: http://rmannibucau.wordpress.com/ >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>> Github: https://github.com/rmannibucau >>>>> >>>>> >>>>> >>>>> 2014-03-18 19:42 GMT+01:00 Matt Benson <mben...@apache.org>: >>>>> > On Tue, Mar 18, 2014 at 1:01 PM, Michael Blyakher >>>>> > <michael.blyak...@gmail.com> wrote: >>>>> >> Hi All, >>>>> >> >>>>> >> Thanks for the quick replies, and apologies for not being more specific >>>>> - I >>>>> >> was quoting the EE 7 Platform spec as I am particularly interested in >>>>> using >>>>> >> the bval 1.1 implementation that hasn't been officially released yet. >>>>> >> >>>>> >> But from what I am hearing, it is the responsibility of an EE server to >>>>> >> handle the WEB-INF case. I can see how this is possible for the 1.0 >>>>> >> implementation, as the server can parse the validation.xml itself and >>>>> >> bootstrap the configuration through the validation spec API's. How >>>>> >> would >>>>> >> this be done for the current 1.1 implementation in the bval-1.1 branch >>>>> in >>>>> >> the repository? I don't see how the values for the >>>>> "executable-validation" >>>>> >> element could be provided to the impl through the validation spec >>>>> >> API's. >>>>> >> >>>>> > >>>>> > Well, the >>>>> http://bval.apache.org/mvnsite/bval-jsr303/apidocs/org/apache/bval/jsr303/ApacheValidatorConfiguration.Properties.html#VALIDATION_XML_PATH >>>>> > property can be used to point to a different resource on the >>>>> > classpath, but I can't find any mechanism that could be used to hook >>>>> > up WEB-INF/validation.xml, and I can't find how TomEE does it, so >>>>> > AFAICT you have indeed found what I consider a problem. Off the top of >>>>> > my head I think we could solve it by adding a simple SPI to discover >>>>> > the default validation configuration resource. Thoughts? >>>>> > >>>>> > Matt >>>>> > >>>>> >> Thanks, >>>>> >> Michael >>>>> >> >>>>> >> >>>>> >> On Tue, Mar 18, 2014 at 12:13 PM, Romain Manni-Bucau >>>>> >> <rmannibu...@gmail.com>wrote: >>>>> >> >>>>> >>> Hi >>>>> >>> >>>>> >>> Bval only looks in META-INF but TomEE for instance (more generally EE >>>>> >>> servers) handles WEB-INF case. >>>>> >>> Romain Manni-Bucau >>>>> >>> Twitter: @rmannibucau >>>>> >>> Blog: http://rmannibucau.wordpress.com/ >>>>> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>> >>> Github: https://github.com/rmannibucau >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> 2014-03-18 17:50 GMT+01:00 Michael Blyakher < >>>>> michael.blyak...@gmail.com>: >>>>> >>> > Hi, >>>>> >>> > >>>>> >>> > Where is the validation.xml supposed to be for a web archive? The >>>>> bval >>>>> >>> > spec's only indicate the "META-INF/validation.xml" location, but the >>>>> EE >>>>> >>> > platform spec indicates that for a web archive this location must be >>>>> >>> > "WEB-INF/validation.xml". >>>>> >>> > >>>>> >>> > EE.5.17 - "The name of the descriptor is WEB-INF/validation.xml for >>>>> web >>>>> >>> > modules and META-INF/validation.xml for all other types of modules." >>>>> >>> > >>>>> >>> > Given this, I don't see anywhere in the bval 1.0 or 1.1 code that >>>>> handles >>>>> >>> > this. Am I missing something or does this implementation not handle >>>>> this >>>>> >>> > case for web archives? >>>>> >>> > >>>>> >>> > Thanks, >>>>> >>> > Michael >>>>> >>> >>>>>
