Java EE platform spec
by Gunnar Morling
Emmanuel, all,
I just came across the following paragraph in section EE.5.16.2 of the
Java EE platform spec [1]:
"For the benefit of implementors, we note that the Bean Validation API
includes a ValidatorFactoryBuilder interface that can be used to create a
ValidatorFactory configured according to the contents of a validation
deployment descriptor in the form of a java.io.InputStream."
I'm not aware of an interface ValidatorFactoryBuilder in BV (Having
searched the web, I assume that there was such an interface in 1.0
preview releases) so I guess the entire paragraph is obsolete. Shall I
create an issue in the spec tracker to have the paragraph removed?
--Gunnar
[1] http://java.net/projects/javaee-spec/downloads/download/JavaEE_Platform_S...
12 years, 3 months
Re: [bv-dev] Support DI within constraint validators
by Emmanuel Bernard
Of of the options is to have it defaulted to enabled. To disable validation or change the default group, @MethodValidated would be necessary.
Is that what the EE spec leads had in mind?
On 22 août 2012, at 13:23, Pete Muir wrote:
> BTW the Java EE spec leads were concerned about the @MethodValidated annotation being required at all.
>
> On 22 Aug 2012, at 12:19, Emmanuel Bernard wrote:
>
>> Yes, one of the consequences as you point out is that we will define the @MethodValidated contract in BV.
>> While I think it's a good thing, I want everyone to understand this consequence.
>>
>> On 15 août 2012, at 22:56, Gunnar Morling wrote:
>>
>>> Hi all,
>>>
>>> based on an issue I recently filed, CDI lead Pete Muir started a
>>> thread on the integration of BV and CDI over on the CDI mailing list
>>> [1].
>>>
>>> The general question is where this integration should be described. My
>>> first assumption was, that the Java EE platform spec. would be the
>>> right place for this is, but Java EE co-lead Bill Shannon pointed out
>>> [2] that the preferred approach is to have such integrations described
>>> in one of the involved technology specs.
>>>
>>> And actually we're already doing this to some degree as of the BV 1.1
>>> early draft [3]. So I guess our descriptions there need just to be a
>>> bit more authoritative ("must" instead of "should" etc.) and specific.
>>> In section 3.7, the CDI spec. currently also mentions built-in beans
>>> for Validator and ValidatorFactory to be provided by a Java EE
>>> container. To consolidate the specs I tend to think that this section
>>> should be merged into BV section 5.5.7.1.
>>>
>>> The same approach should probably also be taken for the description of
>>> triggering method validation under Java EE using the @MethodValidated
>>> annotation.
>>>
>>> Any thoughts?
>>>
>>> --Gunnar
>>>
>>> [1] http://lists.jboss.org/pipermail/cdi-dev/2012-August/001978.html
>>> [2] http://lists.jboss.org/pipermail/cdi-dev/2012-August/002045.html
>>> [3] http://beanvalidation.org/1.1/spec/#d0e6698
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
12 years, 3 months
Support DI within constraint validators
by Gunnar Morling
Hi all,
based on an issue I recently filed, CDI lead Pete Muir started a
thread on the integration of BV and CDI over on the CDI mailing list
[1].
The general question is where this integration should be described. My
first assumption was, that the Java EE platform spec. would be the
right place for this is, but Java EE co-lead Bill Shannon pointed out
[2] that the preferred approach is to have such integrations described
in one of the involved technology specs.
And actually we're already doing this to some degree as of the BV 1.1
early draft [3]. So I guess our descriptions there need just to be a
bit more authoritative ("must" instead of "should" etc.) and specific.
In section 3.7, the CDI spec. currently also mentions built-in beans
for Validator and ValidatorFactory to be provided by a Java EE
container. To consolidate the specs I tend to think that this section
should be merged into BV section 5.5.7.1.
The same approach should probably also be taken for the description of
triggering method validation under Java EE using the @MethodValidated
annotation.
Any thoughts?
--Gunnar
[1] http://lists.jboss.org/pipermail/cdi-dev/2012-August/001978.html
[2] http://lists.jboss.org/pipermail/cdi-dev/2012-August/002045.html
[3] http://beanvalidation.org/1.1/spec/#d0e6698
12 years, 3 months
Re: [bv-dev] Changes in BV XML schemas
by Gunnar Morling
Hi all,
I'm currently implementing this change (new mandatory “version“ attribute
in BV 1.1 XML descriptors) within the RI (see HV-595). The basic idea is to
* examine the root element for the version attribute using a parser (Stax
in our case) and then
* unmarshal the descriptor with JAXB, using the right XSD based on the
retrieved version.
So I have to access the input streams representing the descriptors twice.
This is no problem for the streams we're opening ourselves
(validation.xml), but it could be an issue for streams passed via
Configuration#addMapping().
I can see the following options now:
* read descriptor streams into a string first which then can be processed
several times. Alternatively wrap any streams not supporting the mark/reset
contract into a BufferedInputStream.
* demand in the spec that any passed input stream must support mark/reset.
This would also be beneficial for the scenario of creating several
factories from one Configuration, which we discussed a while ago. But
obviously this would be a non compatible change for 1.0 clients passing non
resettable streams to addMapping().
Any thoughts?
--Gunnar
Am 24.06.2012 11:46 schrieb "Gunnar Morling" <gunnar(a)hibernate.org>:
12 years, 3 months