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
>>>>>>>> >>>
>>>>>>>>

Reply via email to