Method validation - cont'd
by Gunnar Morling
Hi all,
now that some weeks have passed since we've released the BV 1.1 early
draft, I thought it's about time to continue with the method
validation feature [1].
The current spec document [2] contains several TODO markers relating
to method validation which need to be addressed. The most relevant
issues IMO are:
* Align on approach for cross-parameter validation
* Should method validation methods be defined on j.v.Validator or a
dedicated new interface?
* Polish extension for method constraints to meta-data API
* Further discuss @MethodValidated annotation with other EGs (e.g. JAX-RS)
* Should ParameterNameProvider go into a sub-package?
Please see the spec for a more detailed description of these and other
issues. If you have feedback, ideas or questions around any of these
issues, the method validation feature in general or see any issues
currently not yet discussed, please don't hesitate to post to the
list.
I'll start specific discussions on individual items as required. In
parallel the implementation of the feature within the RI will start
[3]. I guess this will create additional insights, too.
I'm looking forward to your feedback,
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-272
[2] http://beanvalidation.org/1.1/spec/
[3] https://hibernate.onjira.com/browse/HV-571
11 years, 11 months
Re: [bv-dev] bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
by Edward Burns
>>>>> On Fri, 4 May 2012 12:11:30 +0200, Hardy Ferentschik <hardy(a)hibernate.org> said:
HF> Seems everyone is tired of OSGi? Maybe adding the OSGi header is as
HF> far as we should go.
For the spec, that's the right amount of depth.
HF> However, I would like to use this thread to a related question - class loading.
HF> At several occasions Hibernate Validator needs to do some class
HF> loading or at least needs a class loader (e.g. loading classes
HF> specified in the xml configuration, detecting whether JPA is on the
HF> classpath in the case of TraversableResolver, loading resource
HF> bundles).
HF> The spec does not define which class loader should be used in these
HF> cases. Hibernate Validator for example first tries the context and
HF> then the current class loader. The question is whether there is a
HF> need to specify which class loader should be used or should there
HF> even be a ClassLoaderService:
HF> public interface ClassLoaderService {
HF> public <T> Class<T> classForName(String className);
HF> // potentially more class loader related methods
HF> }
HF> An implementation of such a service could be passed if we add
HF>
HF> javax.validation.Configuration#classLoaderService(ClassLoaderService).
This is a more fundamental concern than BV, and I think it should be
raised on the JavaEE umbrella JSR list. <http://javaee-spec.java.net>
jsr342-experts(a)javaee-spec.java.net.
HF> I created https://hibernate.onjira.com/browse/BVAL-286. I really
HF> think such a service is beneficial outside the OSGi scope, but even
HF> there it is useful.
HF> Atm I see two main use cases - loading classes and leading resource
HF> bundles
HF> <T> Class<T> classForName(String className);
HF> ResourceBundle loadBundle(String bundleName, Locale locale);
HF>
>>>>> On Mon, 14 May 2012 16:57:14 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org> said:
EB> Note that neither your nor my solution differentiate classloading
EB> depending on what ought to be loaded.
And we also need to consider multi-tenant environments. Perhaps we need
to pass in the tennant ID?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
11 years, 11 months
