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
12 years, 10 months
Bean Validation 1.1 early draft 1 is out
by Emmanuel Bernard
Hi all,
I have pushed the early draft we have been discussion for a while now to the JCP. I also put a copy in the open. Check out http://goo.gl/FlAuQ
It contains main TODOs I would like your opinion on. But that's a significant work that moves dependency injection and method-levle validation forward. We will be able to focus on the next items in our roadmap.
Emmanuel
PS: sorry for the delay in sending this email. I basically sent it to the wrong mailing list :)
12 years, 10 months
Java version for BV 1.1
by Gunnar Morling
Hi Emmanuel,
is there a certain Java version which can be assumed for BV 1.1?
I think Hardy once told me that JEE 7 and thus BV 1.1 will be based on
Java 6, but I'm not totally sure anymore.
Thanks,
--Gunnar
12 years, 11 months
Tightly coupled validation
by Cemo
Hi,
I am not sure is this already discussed or not but currently I believe that
validation spec is very strict about coupling.
For example at interface level validator is declared by Interface.
@Constraint(validatedBy = *EmailValidator.class*)
@Retention(RUNTIME)
public @interface *Email *
And for the part EmailValidation part, we are referring again our Email
Interface
public class *EmailValidator *implements ConstraintValidator<*Email*,
String>
What I think is this contract is little tight. And because of the strict
contract, splitting validation by its interface is not possible.
And let me to clarify my use case too.
I have splitted my domain, validation and web projects (Web1, Web2, Web3)
and using spring extensively.
- Domain (Has no dependency)
- Validation (Has dependency to validation spec and optionally Spring
Framework. For example, It can validate an uniqueEmail field by checking
database. )
- Web's (Has dependency to validation and domain)
My domain needs dependency to validation for validating it but it means
also depending spring and all other stuffs regarding Database validations.
What I want to split Validation contract to interfaces and implementations.
Interfaces could be declared at domain and implementations reside at
validation module. Validation module has a dependency to domain perfectly.
I have checked builtin constraints implementations but it seems there is
not any extensible points for it.
What are your suggestions for this situation?
Thanks
12 years, 11 months
Re: [bv-dev] bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
by Edward Burns
>>>>> On Tue, 15 May 2012 10:42:12 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org> said:
EB> On 14 mai 2012, at 21:06, Gunnar Morling wrote:
EB> Should the application developer write a module that will bootstrap
EB> Bean Validation? That the thing I want to avoid, having the user do
EB> useless heavy lifting.
HF> In the end it is up to the framework providers to make it as simple
HF> as possible to use Bean Validation for modules/apps running within
HF> the framework. All Bean Validation needs to provide is a way to set
HF> the class loader.
Speaking on behalf of the provider of the JSF framework (a BV consuming
technology), I think I want the BV spec to say something like,
"Implementations must do X and Y and then a ValidatorFactory will be
available." I am fine if X and Y are expressed in terms of OSGi APIs.
GM> a) The user indeed bootstraps BV (passing the class loader) and
GM> registers VF as OSGi service. This would be done using a bundle
GM> activator roughly like that:
GM> b) The BV provider's OSGi bundle performs the registration of the VF.
GM> The required class loader would be provided via a ClassLoaderService,
GM> for which the user has to register an implementation in his activator:
If a) obviates the need for the whole icky (and really not appropriately
located (see below)) ClassLoader service, I'd rather have a). Yes, it's
more code, but it's code the container vendor writes once. In the end,
Oracle's containers use HVAL anyway.
>>>>> On Mon, 14 May 2012 09:40:07 -0700, Edward Burns <edward.burns(a)oracle.com> said:
Eddie> This is a more fundamental concern than BV, and I think it should be
Eddie> raised on the JavaEE umbrella JSR list. <http://javaee-spec.java.net>
Eddie> jsr342-experts(a)javaee-spec.java.net.
I'd really like to not have a ClassLoader service in a (sub-) package
javax.validation. If anything, javax.enterprise.util seems a better
home.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
12 years, 12 months
Re: [bv-dev] BVAL-234 @NotNull @Id for JPA and Bean Validation
by Gunnar Morling
2012/5/21 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 21 mai 2012, at 21:06, Gunnar Morling wrote:
>
>> 2012/5/21 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>
>>> On 15 mai 2012, at 19:50, Gunnar Morling wrote:
>>>
>>>> I also find disabling validation of @NotNull by default problematic.
>>>> If I'm for instance using sequences for id generation, then @NotNull
>>>> should be validated upon insertion. But relying on sequences is IMO
>>>> per se not portable; so when deciding to use them, I'd also expect
>>>> @NotNull to be validated.
>>>
>>> I think you misunderstood something. If sequence, table generation or
any in memory generation logic is used, then @NoNull will indeed be
validated in option #3. In fact, database trigger and column id generations
are the only one that would disable validation.
>>
>> Ah, I see. Indeed I thought that you meant to disable validation of
>> @NotNull in any case. If the behavior depends on the applied id
>> generation strategy, #3 makes more sense.
>>
>> I'm not sure, does the JPA spec define that sequence values are always
>> to be prefetched? Otherwise I could imagine situations where an
>> allocation size of 1 is used, which would allow to fetch the sequence
>> just within the INSERT statement. In that case I think the constraints
>> again couldn't be validated.
>
> The JPA provider implementation would know such thing and act accordingly.
Right. I guess what I'm just not totally comfortable with is the fact that,
when looking at an entity, it gets a bit more complicated to understand
whether a @NotNull constraint is validated or not.
By defining a validation group such as @PreUpdate and putting the @NotNull
constraint into that group a user could solve the issue in an
easy-to-understand way leveraging the existing mechanisms.
I see that such a feature would probably help to give a better
"it-just-works" experience. But one could also argue that using a sequence
(or another id generation strategy not providing a value before the insert)
and a @NotNull constraint within a group which is validated upon insertion
represents an inconsistency within the data model.
On a more practical side: How would a JPA provider implement that feature?
The simplest would probably be to validate all constraints and then ignore
any id-related violations based on the chosen generation strategy. Or do
you think we should define a way to control whether certain constraints are
to be excluded by the BV runtime?
--Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12 years, 12 months
BVAL-234 @NotNull @Id for JPA and Bean Validation
by Emmanuel Bernard
There is an annoyance when using JPA and Bean Validation today. I worked out a proposal. Please let me know what you think
http://beanvalidation.org/proposals/BVAL-234/
--- (copied here for convenience) ---
[Link to JIRA ticket][jira]
See also [NetBeans issue][netbeans]
## Problem description
Today when a property marked @Id @GeneratedValue is also marked @NotNull, it will fail if the identity generation is post-insert
in the database. This can be the case if the underlying table is using column id generation for example.
The id property is thus null when Bean Validation is executed during the pre-persist phase and a constraint
violation is raised.
## Solutions
### 1. User adjusts
One option is to stay put and consider the behavior valid. The user can work around that by:
- creating a `com.acme.groups.Created` group
- marking the `@NotNull` annotation as belonging to the group
- override the groups in `persistence.xml` to validate `Created` accordingly
Here is the snipped of the `persistence.xml` file
<property name="javax.persistence.validation.group.pre-persist"
value="javax.validation.groups.Default"/>
<property name="javax.persistence.validation.group.pre-update"
value="javax.validation.groups.Default,com.acme.groups.Created"/>
### 2 User adjusts with some help
We could use option 1 but have JPA provide the created group: `javax.persistence.validation.groups.Created`
### 3. Have JPA disable validation of id properties at pre-persist
JPA could disable validation on id properties if in pre-persist and if the generated value is not created yet.
Note that we disable all validations - not simply `@NotNull` - as it does not make much sense to execute other
validations when a property is null.
`TraversableResolver` can be used to solve the problem as `isReachable` can stop the processing of a property.
### Conclusions
Option 3 seems the most reasonable but it could be complicated at the JPA level.
Before going to the JPA EG, let's discuss the situation here.
### Questions remaining
- should the `Created` groups be renamed?
- is that correct to sneakily disable @NotNull constraint validation?
[netbeans]: http://netbeans.org/bugzilla/show_bug.cgi?id=197845#c3
[jira]: https://hibernate.onjira.com/browse/BVAL-234
12 years, 12 months
Re: [bv-dev] [BVAL-286] Class loading service
by Gunnar Morling
Am 19.05.2012 14:45 schrieb "Hardy Ferentschik" <hardy(a)hibernate.org>:
>
>
> On May 18, 2012, at 4:38 AM, Michael Nascimento wrote:
>
> > Issues like this:
> >
> > https://hibernate.onjira.com/browse/HHH-7084
> >
> > Thread Context ClassLoader is the de facto standard these days. If we
> > choose to actually defining and allowing classloading to be
> > customized, the default must be TCCL.
>
> Funny that you that. We had just had an Hibernate Validator issue not so
long ago where
> a modular system expert told us just the opposite. Don't use TCCL first
;-)
>
> I think the bottom line is that there is no standard. Checking TCCL first
and then the
> current class loader was a strategy which Hibernate applied for quite
some time.
> It proved to be a good approach for quite some time. However, the current
trend seems to be
> to make the class loading more configurable and allow to for example pass
a class loader.
Yepp, I think that's the best way.
The default behavior could be the one you describe, but if a specific
classloader is configured by the user, this one should be taken to load
user provided resources and classes.
AFAIK under OSGi it's not defined what CL is set as the TCCL, so one can't
really rely on it there.
--Gunnar
>
> --Hardy
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12 years, 12 months
