Well if we can avoid to fork/branch tomee before next release would be awesome but yes it sonds reasonable and avoiding jvm SPI is awesome 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 17:10 GMT+01:00 Matt Benson <gudnabr...@gmail.com>: > Actually, come to think of it, we don't have to do it as a "services" > SPI at all; we can just define the interface and have it be a custom > config item for ApacheValidatorConfiguration. This makes it more > explicit and TomEE can just specify when bootstrapping--hopefully, > anyway. We'll see if there are any gotchas and hopefully we can get it > working in a TomEE branch or fork before we set it in stone. Okay? > > Matt > > On Wed, Mar 19, 2014 at 11:06 AM, Matt Benson <gudnabr...@gmail.com> wrote: >> Well, in that case I don't see how we can really go wrong there. I'll >> try to remember to do this as I'm hacking BVal in the coming weeks and >> maybe we can then see how it looks in TomEE. >> >> Matt >> >> On Wed, Mar 19, 2014 at 11:00 AM, Romain Manni-Bucau >> <rmannibu...@gmail.com> wrote: >>> that's what I was thinking about but when I hacked 1.1 branch I was >>> really thinking adding it when integrating tomee to avoid a useless or >>> wrong SPI. >>> 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:59 GMT+01:00 Matt Benson <gudnabr...@gmail.com>: >>>> So are you proposing the SPI look more like: >>>> >>>> public interface DefaultValidationConfigProvider { >>>> org.apache.bval.jsr.xml.ValidationConfigType >>>> getDefaultValidationConfig(); >>>> } >>>> >>>> ? >>>> >>>> Matt >>>> >>>> On Wed, Mar 19, 2014 at 10:57 AM, Romain Manni-Bucau >>>> <rmannibu...@gmail.com> wrote: >>>>> Cause: >>>>> 1) TomEE added some features relying on internal config (placeholders etc) >>>>> 2) TomEE uses its own model for all EE descriptors whatever the spec is >>>>> >>>>> That's not an issue on BVal side but it will need to be integrated >>>>> without forking as much as possible >>>>> >>>>> 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:52 GMT+01:00 Matt Benson <gudnabr...@gmail.com>: >>>>>> 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 >>>>>>>>>>> >>> >>>>>>>>>>>
