Re: [bv-dev] Method Validation: Why Example 4.11 should be allowed
by Gunnar Morling
Am 18.07.2012 18:51 schrieb "Paul Benedict" <pbenedict(a)apache.org>:
>
> Gunnar, thank you for writing back!
>
> On Tue, Jul 17, 2012 at 4:12 PM, Gunnar Morling wrote:
> > Hi Paul,
> >
> > thanks for your feedback, that's much appreciated.
> >
> > The reason for the restriction basically is that a client of an API
> > doesn't necessarily know its implementation. Let's for instance assume
> > a client receives an implementation of the OrderService interface via
> > dependency injection:
> >
> > public class Shop {
> >
> > @Inject
> > private OrderService orderService;
> >
> > ...
> > }
> >
> > Here, the programmer of the Shop class doesn't know which
> > implementation will be injected, maybe it's SimpleOrderService, maybe
> > it's an implementation type not even known to the Shop programmer at
> > all. If it would be legal to add parameter constraints to the
> > OrderService implementation, there is no way to find out for the
> > caller what parameter values for placeOrder() are valid.
>
> I see your viewpoint. However, I am not sure BeanValidation needs to
> be this smart.
This is not specific to BV. OO design in general has the notion that any
sub-type can be used where its super-types can be used. This principle is
violated if parameter constraints could be added to sub-types, putting more
constraints in place to be obeyed by the caller.
>
> Let's make up an example.
> 1. OrderService is a popular interface in the public domain for several
years.
> 2. OrderService was created years before BeanValidation exists.
I don't see a difference depending on when an interface was written.
Imagine it would be allowed to add parameter constraints in implementations
of java.util.List. Such an implementation would potentially break all code
written against the List interface which is not aware of the additional
constraints.
> 3. OrderService constraints are documented in the javadoc. A custom
> Exception type is thrown.
> 4. A new vendor wishes to implement SimpleOrderService using Bean
> Validation. Their plan is to capture ConstraintViolationException and
> marshall it to the custom Exception type.
The idea behind BV method validation is that some integration layer (e.g.
CDI, AOP,based etc.) performs the constraint validation. So any
ConstraintViolationException would not be reachable from within
SimpleOrderService, as the call flow wouldn't get there.
>
> The new vendor will not be able make such a design under the current
> spec. This is where the rub lies: assuming the lack of BeanValidation
> means the validation constraints are specified. Is this sensible?
> Actually, in this case, no constraints assumes all data is
> automatically valid.
I'm not sure whether I can follow.
>
> I believe it should be the opposite -- constraints are undefined.
> Because a plethora of popular interfaces exist without BeanValidation,
> the spec should give leniency to the situation.
>
> Would you consider a new annotation that prevents the strengthening or
> loosening of validation? Perhaps you need something like this:
>
> @ValidationConstraintsComplete
> public interface OrderService {
> void placeOrder(String customerCode, Item item, int quantity);
> }
At the moment I don't see that this would help. If OrderService was written
without BV in mind, the annotation can't be added there. If it was written
with BV in mind, why not placing any parameter constraints on the interface?
> Thanks!
> Paul
--Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11 years, 8 months
Hosting of method validation methods
by Hardy Ferentschik
Hi all,
Let me pick up yet another TODO from the current spec.
Section "5.1.2. Method-level validation methods" [1] still contains a TODO whether the methods for method validation should be hosted
on a different interface (other than javax.validation.Validator).
At the moment all validation methods are hosted on javax.validation.Validator. Personally I don't see a strong reason for introducing
another indirection/interface. Does anyone have objections removing the todo?
--Hardy
[1] http://beanvalidation.org/1.1/spec/#d0e3831
11 years, 8 months
BVAL-292 / BVAL-293 ConfigurationSource rename and behavior clarification
by Hardy Ferentschik
Hi all,
I think it is time to wrap some of our latest discussion to be able to move on.
Let's start with ConfigurationSource. Hopefully you remember that we discussed renaming it [1][2].
To make this more concrete I went ahead and already created a pull request for the API [3] and the
spec [4].
I renamed ConfigurationSource to XMLConfiguration (as it already used to be called once)
and stated in the configuration that Configuration#getXMLConfiguration returns the information
from META-INF/validation.xml. It also specifies that Configuration#getXMLConfiguration never returns null,
but rather the corresponding getters will return null respectively the empty set or map.
Initially I thought about using DefaultConfiguration as an alternative name, but as Emmanuel pointed out
in an earlier email it clashes to a certain degree with the programmatic Configuration interface.
In the end I went back to XMLConfiguration especially after reading Gunnar's summary around this issue:
{quote}
AFAICS the original idea behind ConfigurationSource was to provide a
way for BV integrators (e.g. CDI, or maybe an OSGi container etc.) to
access the stuff from the BV default configuration (validation.xml)
and make use of this when providing e.g. a validator in their specific
environment. E.g. CDI might provide a CDI-enabled validator using the
message interpolator from validation.xml. ConfigurationSource spares
such integrators from having to parse validation.xml on their own.
ConfigurationSource IMO shouldn't address any needs specific to an
integration technology. So if for instance OSGi wanted to configure
the constraint validator factory via the OSGi configuration service (a
standard configuration API there), they would have to do that in the
code integrating with BV (likely merging/delegating to the default
configuration retrieved via ConfigurationSource).
So the only scenario I can see where ConfigurationSource would
represent something other than validation.xml, would be a BV provider
which provides another means of default configuration.
{quote}
Regarding the last point, I don't see why for example Hibernate Validator should choose
a different default configuration option than validation.xml. And if we would I would consider
it a provider specific feature which does not have to be (indirectly) reflected in the spec.
Thoughts?
--Hardy
Btw, Feel free to also comment on the pull requests as well. Hopefully we can come to
an agreement within the next couple of days.
[1] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-May/000389.html
[2] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-June/000390.html
[3] https://github.com/beanvalidation/beanvalidation-api/pull/10
[4] https://github.com/beanvalidation/beanvalidation-spec/pull/8
11 years, 9 months
Method Validation: Why Example 4.11 should be allowed
by Paul Benedict
I think there is a general problem with the application of this rule:
"a method's preconditions (as represented by parameter constraints)
may not be strengthened in sub types"
The problem is that this could hurt API developers who publish basic
interfaces but where implementation designers are free to choose
validations specific to their system. Example 4.11 is a great example:
public interface OrderService {
void placeOrder(String customerCode, Item item, int quantity);
}
public class SimpleOrderService implements OrderService {
@Override
public void placeOrder(
@NotNull @Size(min=3, max=20) String customerCode,
@NotNull Item item,
@Min(1) int quantity) { ... }
}
I can see no good reason why this should be disallowed. The spec is
assuming that because no constraints are on the interface, no
implementation may ever use constraints. This is a poor assumption. It
is actually a blockade to any system that currently exists -- being
created prior to BeanValidation -- who could benefit from adding
method-level validation in their implementation.
This can be easily corrected though. Apply these rules only on
concrete classes. If SimpleOrderService2 extends SimpleOrderService,
then spec should disallow the strengthening of constraints. In
summary, don't consider interfaces (unless the interfaces themselves
have annotated constraints?).
Do you see the problem I am addressing?
Thanks,
Paul
11 years, 9 months
Re: [bv-dev] MessageResolver vs ResourceBundleLocator
by Gunnar Morling
Am 30.06.2012 13:46 schrieb "Gerhard Petracek" <gerhard.petracek(a)gmail.com>:
>
> hi hardy,
>
> thx for moving it to an own thread!
>
> a copy of my last answer:
>
> ...
> it's just about:
> - an interface which directly allows simple but still flexible custom
implementations of (custom) message-sources (including a simple delegation
to a ResourceBundle) - see [1].
> vs.
> - an interface which is restricted to ResourceBundle. -> if it isn't
possible to use ListResourceBundle or PropertyResourceBundle, users have to
implement #getKeys which might not be possible (/ that easy) for some
advanced use-cases.
>
What's that 2nd interface required for? Wouldn't it suffice to do all
lookups via the first interface and demand in the spec, that the default
implementation of that interface returns values based on the
ValidationMessages bundle?
What are the advanced use cases you have in mind?
> the rest is more or less the same - if the MessageInterpolator receives a
key, it uses the new interface for the lookup (if there is no custom
implementation of the new interface or no result for the given key, the
existing default bundle (ValidationMessages) is used as a fallback).
Sounds reasonable to me. We should expose the default implementation of the
interface during bootstrap so that custom implementations can also delegate
to it.
>
> regards,
> gerhard
>
--Gunnar
> [1]
https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/core/...
>
>
> 2012/6/26 Hardy Ferentschik <hardy(a)hibernate.org>
>>
>>
>> On Jun 26, 2012, at 8:21 AM, Gunnar Morling wrote:
>>
>> > I thin I've not yet totally understood what you have in mind.
>>
>> AFAIU Gerhard proposes a more general interface which is independent
from ResourceBundles. Underneath you still can use them, in fact you would
have to for
>> ValidationMessages.properties. We would have to to define the
MessageResolver interface and then also define that the default
implementation of this interface
>> resolves against ValidationMessages.properties. Even with the
ResourceBundleLocator interface you need to somehow specify that a default
implementation exists
>> which uses ValidationMessages.properties. Is this what you have in mind
Gerhard?
>>
>> > Maybe you could create a proposal for BVAL-217 describing things more
in detail (interaction between resolver and interpolator, integration with
BV 1.0 interpolators etc.)?
>>
>> +1 That would be the best.
>>
>>
>> > I also think using resource bundles is not totally optional as there
is the ValidationMessages bundle.
>>
>> Right. For that reason using ResourceBundleLocator still feels a little
more "natural" to me.
>>
>> --Hardy
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
11 years, 9 months
BVAL-265 - Expose settings defined in XML in the Configuration API
by Hardy Ferentschik
Hi,
While working on the implementation of 1.1.0.Alpha1 I came across BVAL-265.
Basically the follwoing method got added to Configuration:
/**
* Return information stored in the configuration source (typically the <i>META-INF/validation.xml</i>
* file).
* Implementations are encouraged to lazily build this object to delay parsing.
*
* @return {@code ConfigurationSource} object
*/
ConfigurationSource getConfigurationSource();
Where ConfigurationSource exposes the different bootstrap parameters as strings, e.g. getMessageInterpolatorClassName()
For me the following questions arise:
* How do I interpret "typically the "META-INF/validation.xml file" - typically implies an alternative. Is there is one how do I
differentiate between these alternatives? Shouldn't the docs read "Return information stored in META-INF/validation.xml"?
* What do I return if there is no validation.xml? null? Or the class names of the implementations default implementations?
* Last but not least, why ConfigurationSource? If I look at the class I see configuration parameters so why not call this
(ValidationXml)ConfigurationParamters or (ValidationXml)BootstrapParameters. "Source" implies for me that I can get information about
how the configuration was provided, e.g. XML vs programmatic.
Thoughts?
--Hardy
11 years, 9 months
Bean Validation and JAX-RS 2.0
by Gunnar Morling
Hi all,
Emmanuel and I have been discussing the integration of BV and JAX-RS
(RESTful web services) with the JAX-RS 2.0 EG.
The basic idea is to place constraint annotations on JAX-RS resource
types and perform a validation of the same at defined times in the
request life cycle. In particular, JAX-RS makes use of the new method
validation API to validate parameters and return values of resource
methods.
The JAX-RS 2.0 EG recently published their third early draft for
public review [1], so in case you're interested, you might have a look
at the spec (chapter 7 describes the BV integration) and provide your
feedback. I think simplest is if you post any comments to both EGs
(the JAX-RS mailing lists can be found at [2]).
Thanks,
--Gunnar
[1] http://jcp.org/en/jsr/detail?id=339
[2] http://java.net/projects/jax-rs-spec/lists
11 years, 9 months
Re: [bv-dev] Javascript export of bean validation rules
by Edward Burns
MI> I was discussing this topic with Emmanuel Bernard by email and
MI> Emmanuel suggested that we move this conversation to this
MI> mailing-list, so here I am :).
MI> The idea would be to propose a javascript export of the bean
MI> validation rules.
HF> What exactly do you want to export? An JavaScript implementation of
HF> the default constraints? Do you have already some concrete ideas?
EB> When I saw this idea right here, moments ago, my first thought was to
EB> specify a JSON format for validation rules and require the existence of
EB> some tool that you could point at a bunch of java code that happens to
EB> have JSR-303 annotations on it and the tool would generate that JSON.
EB> The JSON format would be designed such that the fidelity of the rules
EB> would be mostly maintained such that a corresponding piece of code on
EB> the client side could slurp it down and carry out the rules.
HF> I am not sure I am following you. JSON is really just a transport
HF> protocol for some data, right? Where is the actual validation
HF> logic? Or is this what you want to generate via the tool?
It's possible to encode JavaScript functions in JSON. That's what I was
thinking of here. I don't want to write that code myself, though!
>>>>> On Sat, 30 Jun 2012 12:02:19 +0200, Gerhard Petracek <gerhard.petracek(a)gmail.com> said:
GP> 3 years ago we started to brainstorm such an idea for bv+jsf and we
GP> came up with 10 very basic requirements. however, there are too
GP> many different ideas out there how it should work and each of them
GP> isn't trivial (+ has some issues). since validation via
GP> ajax-requests doesn't have most issues we identified with a
GP> client-side approach and it's available in jsf already, we stopped
GP> working on it.
>>>>> On Sun, 1 Jul 2012 11:28:14 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org> said:
EmmanualB> See below the proposal Pete Muir, Gerhard and I wrote for
EmmanualB> client side JSF back in 2008. This proposal did not go
EmmanualB> further at the time because we felt it would be too much for
EmmanualB> a v1 of the JSF-BV integration. It does not involve sending
EmmanualB> the metadata via JSON but rather specify how to write the
EmmanualB> piece of Javascript responsible to validate a given value for
EmmanualB> a given constraint and let the client side web framework wire
EmmanualB> this altogether.
That works too. In any case, it's perfectly acceptable to decline to
satisfy a use-case in the spec, leaving it for non-spec technology to
satisfy. It's funny, JSON is also creeping its way into JSF 2.2, but
the majority of experts seem to prefer to leave it out.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 14 Business days til JSF 2.2 Public Review to EG
11 years, 10 months
Re: [bv-dev] Bean Validation and JavaFX
by Edward Burns
>>>>> On Sat, 30 Jun 2012 19:53:20 +0200, Gunnar Morling <gunnar(a)hibernate.org> said:
EmmanuelB> It might make sense for us to add support of JavaFX types in
EmmanuelB> the spec. Implementations could use some lazy "binding" in
EmmanuelB> case JavaFX is not there. Are these types stable and few or
EmmanuelB> do they change every other morning?
GM> Personally, I find the option of adding support for types of specific
GM> APIs/frameworks to BV not really appealing. Maybe another API than
GM> JavaFX appears tomorrow?
GM> Another problem I see with GUI validation is that one typically wants
GM> to validate form values before putting them into the model. This works
GM> fine for property-level constraints (using Validator#validateValue()),
GM> but we have nothing to offer for class-level constraints here.
EmmanuelB> That would mean some small duplication but the form itself is
EmmanuelB> an object right? We could put the (class level) constraint
EmmanuelB> declarations on it.
GM> I'm not really sure. AFAICS the form/controller class would have
GM> members of types such as Label, TextField etc, while the a validator
GM> for a class level constraint of the model would operate on the bean's
GM> attribute types. One could think about creating a second validator for
GM> the form types. But I'm not really a JavaFX expert :)
For what it's worth, this "validate values before putting them into the
model" is *exactly* what the BV + JSF integration has always done, since
JavaEE 6. Here's some text from the JSF spec about it [1].
Obtain the ValidatorContext from the ValidatorFactory.
Decorate the MessageInterpolator returned from
ValidatorFactory#getMessageInterpolator with one that leverages the
Locale returned from UIViewRoot.getLocale(), and store it in the
ValidatorContext using ValidatorContext#messageInterpolator.
Obtain the javax.validation.Validator instance from the
validatorContext.
Obtain a javax.validation.BeanDescriptor from the
javax.validation.Validator. If hasConstraints() on the BeanDescriptor
returns false, take no action and return. Otherwise proceed.
Call javax.validation.Validator#validateValue, passing valueBaseClass,
valueProperty, the value argument, and validatorGroupsArray as
arguments.
If the returned Set<ConstraintViolation> is non-empty, for each
element in the Set, create a FacesMessage where the summary and detail
are the return from calling ConstraintViolation#getMessage. Capture
all such FacesMessage instances into a Collection and pass them to
ValidatorException.ValidatorException(java.util.Collection), throwing
the new exception.
>>>>> On Sun, 1 Jul 2012 13:00:52 +0200, Gunnar Morling <gunnar(a)hibernate.org> said:
GM> Today BV is focused on actual Java types adhering to the JavaBeans
GM> convention (types with getters/setters), but there are use cases where
GM> one may have another type model but still would like to use the BV
GM> validation approach.
GM> My thinking was to provide an SPI which allows to customize the way BV
GM> interacts with type models. This SPI would establish an abstract type
GM> model used by the BV runtime. This model would know about "types",
GM> "properties" and so on, but these wouldn't necessarily have to be
GM> actual Java types with bean properties.
Gunnar, is it possible for you to craft this usage of BV in terms of a
pattern of invoking the validateValue() method rather then inventing
another SPI, which, by its very nature of being "yet another SPI" is
bound to be seen as baroque at some level?
>>>>> On Sun, 1 Jul 2012 15:13:50 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org> said:
EmmanualB> Yes I am not convinced there us such demand for such
EmmanualB> feature. And that would definitively be a big undertaking.
EmmanualB> What do others think?
I'd like to avoid it if possible. It's hard enough for one to get one's
head around what we have already, when coming in from the outside, and
looking at JavaEE as a whole.
Ed
[1] https://maven.java.net/service/local/repositories/releases/archive/javax/...
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 13 Business days til JSF 2.2 Public Review to EG
11 years, 10 months