-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 15 posts ] 
Author Message
 Post subject: ConstraintValidator couples implementation details
PostPosted: Sun Mar 30, 2008 12:24 am 
Newbie

Joined: Sun Mar 30, 2008 12:19 am
Posts: 15
ConstraintValidator as an annotation means that the annotations and the implementation of their validator are coupled.

This means that someone attempting to publish a jar just specifying the common API would be publishing annotations that point to an implementation of the constraint. This could cause problems with multiple implementations of the JSR.

A possible resolution to this is to have the annotations just annotated themselves with say @Validator, and ConstraintFactory take the annotation rather than the constraint class.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 30, 2008 7:26 am 
Newbie

Joined: Sun Mar 30, 2008 7:09 am
Posts: 3
Location: The Ether
I disagree that this is a tight coupling (annotations do not have behavior semantics, they are just benign metadata). It is trivial to compile with a replaced annotation jar.

In any event, you can use xml instead of annotations to bind the validator if this is uncomfortable to you.

Also, there is a constraint factory for integration with third-party dependency injection libraries like Guice, and others, which uses the class as a key to retrieve the instance. Depending on the factory implementation the constraint could refer to an abstract class or interface (with no impl details).

_________________
Dhanji R. Prasanna
JSR-303 Expert Group member

Fee Fi Fo Fum, do you smell Dependency Injection?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 30, 2008 2:54 pm 
Newbie

Joined: Sun Mar 30, 2008 12:19 am
Posts: 15
dhanji wrote:
I disagree that this is a tight coupling (annotations do not have behavior semantics, they are just benign metadata). It is trivial to compile with a replaced annotation jar.


The metadata to constraint is analogous to marking an interface with the implementing class for the system. It certainly makes a user implementing a new constraint easier, but makes 'standard' annotations need to have either standardized implementations or per-vendor implementation packages.

To put another way, it could also be considered analogous to dropping the ConstraintValidator classname completely and requiring the annotations to instead have an inner class called ConstraintImpl that implements them.

dhanji wrote:
In any event, you can use xml instead of annotations to bind the validator if this is uncomfortable to you.

Also, there is a constraint factory for integration with third-party dependency injection libraries like Guice, and others, which uses the class as a key to retrieve the instance. Depending on the factory implementation the constraint could refer to an abstract class or interface (with no impl details).


(Since ConstraintFactory today has no tie into validator or any other part of the system, I'll assume that will be possible later)

Yes, there are ways around this, but they are very gross. I would have to have a constraint factory that knows the per-vendor implementation details to know which class type to return a different implementation for. This is why I suggested having the factory instead take the annotation itself.

For standardized constraints, I would expect an implementation to know its implementation of the constraint validators anyway. Perhaps making the ConstraintValidator class parameter optional, so it could be omitted for standards-defined constraints?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 01, 2008 11:59 am 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
dwaite wrote:
The metadata to constraint is analogous to marking an interface with the implementing class for the system. It certainly makes a user implementing a new constraint easier, but makes 'standard' annotations need to have either standardized implementations or per-vendor implementation packages.

To put another way, it could also be considered analogous to dropping the ConstraintValidator classname completely and requiring the annotations to instead have an inner class called ConstraintImpl that implements them.


Actually this is not entirely true. Becasue @constraintValidator is an interface, it will not result in a CNFE at runtime (you still need the class at compile time though).

WRT the standard annotations, you are correct and we are talking about introducing some XML mechanism to softly link an annotation to a constraint implementation. The primary goal is to allow the spec to declare built-in annoations but let the different providers to bring their own implementation (less bug in the spec :) ).

Quote:
dhanji wrote:
In any event, you can use xml instead of annotations to bind the validator if this is uncomfortable to you.

Also, there is a constraint factory for integration with third-party dependency injection libraries like Guice, and others, which uses the class as a key to retrieve the instance. Depending on the factory implementation the constraint could refer to an abstract class or interface (with no impl details).


(Since ConstraintFactory today has no tie into validator or any other part of the system, I'll assume that will be possible later)

Yes, there are ways around this, but they are very gross. I would have to have a constraint factory that knows the per-vendor implementation details to know which class type to return a different implementation for. This is why I suggested having the factory instead take the annotation itself.

For standardized constraints, I would expect an implementation to know its implementation of the constraint validators anyway. Perhaps making the ConstraintValidator class parameter optional, so it could be omitted for standards-defined constraints?


See my comment above. Note that providing the annotation to the constraint factory is not a good approach as it would externalize the discovery mechanism: this mechanism should be well defined and standardized which mean handled by the bean validation provider.

Let's dream a bit.
In a perfect world, I would like the @ConstraintValidator annotation to be reversed and placed on the implementation rather than the annotation constraint. But it requires to either:
- list all the constraint implementations in an XML file
- do some kind of scanning

The scanning does not work for this spec as there is not well defined scope to look at.

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 01, 2008 3:02 pm 
Newbie

Joined: Sun Mar 30, 2008 12:19 am
Posts: 15
emmanuel wrote:
dwaite wrote:


Actually this is not entirely true. Becasue @constraintValidator is an interface, it will not result in a CNFE at runtime (you still need the class at compile time though).

WRT the standard annotations, you are correct and we are talking about introducing some XML mechanism to softly link an annotation to a constraint implementation. The primary goal is to allow the spec to declare built-in annoations but let the different providers to bring their own implementation (less bug in the spec :) ).


Excellent.

emmanuel wrote:
dwaite wrote:
In any event, you can use xml instead of For standardized constraints, I would expect an implementation to know its implementation of the constraint validators anyway. Perhaps making the ConstraintValidator class parameter optional, so it could be omitted for standards-defined constraints?


See my comment above. Note that providing the annotation to the constraint factory is not a good approach as it would externalize the discovery mechanism: this mechanism should be well defined and standardized which mean handled by the bean validation provider.


Ahh, so a ConstraintFactory should only know about creation and not discovery, and there isn't a plan to create an extensible discovery mechanism (at least in the specification) because that goes contrary to having standard mechanisms.

emmanuel wrote:
Let's dream a bit.
In a perfect world, I would like the @ConstraintValidator annotation to be reversed and placed on the implementation rather than the annotation constraint. But it requires to either:
- list all the constraint implementations in an XML file
- do some kind of scanning

The scanning does not work for this spec as there is not well defined scope to look at.


Both ways seem fine, but reversing the flow would increase the need for a discovery mechanism (to specify which Constraint class to choose for a particular annotation that both support).


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 02, 2008 6:26 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
I am not categorically opposed to a pluggable discovery mechanism, but unless someone comes with a compelling use case...

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 02, 2008 6:54 pm 
Newbie

Joined: Mon Mar 31, 2008 12:05 pm
Posts: 11
I like how JSR 223 (Bean Scripting) handles the discovery. It would allow you to run multiple validation frameworks concurrently without running into collision issues.

Best Regards,
Richard L. Burton III


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 2:14 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
What you describe Richard is how to retrieve the validation engine (which we will need to describe in the spec at some point).
What we were talking about is how to map a constraint annotation to it's implementation.

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 2:19 pm 
Newbie

Joined: Mon Mar 31, 2008 12:05 pm
Posts: 11
OK, sorry about the mix up.

I hate to throw my 2 cents out there, but I tend to lean toward convention in this case. Grails shows how powerful convention over configuration can be. Instead of decorating a given annotation with yet another annotation, what about applying a naming convention.

E.g.,

@javax.validation.annotations.Nullable expects a class located javax.validation.annotations.NullableValidator that implements the JSR interface.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 2:20 pm 
Newbie

Joined: Mon Mar 31, 2008 12:05 pm
Posts: 11
OK, sorry about the mix up.

I hate to throw my 2 cents out there, but I tend to lean toward convention in this case. Grails shows how powerful convention over configuration can be. Instead of decorating a given annotation with yet another annotation, what about applying a naming convention.

E.g.,

@javax.validation.annotations.Nullable expects a class located javax.validation.annotations.NullableValidator that implements the JSR interface.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 3:00 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
rburton wrote:
OK, sorry about the mix up.

I hate to throw my 2 cents out there, but I tend to lean toward convention in this case. Grails shows how powerful convention over configuration can be. Instead of decorating a given annotation with yet another annotation, what about applying a naming convention.

E.g.,

@javax.validation.annotations.Nullable expects a class located javax.validation.annotations.NullableValidator that implements the JSR interface.


Because contrary to Grails we can use a plain type safe IDE that points us in one click to the implementation :)

Remember, Grails makes heavy uses of Convention over configuration (CoCo ? :) ) because:
- it had no real way to express metadata in the code (namely no annotation): annotation support in Groovy came later.
- they rely on a dynamic language

Anyway, we are talking about one line of code.

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 3:01 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
oh an you need the annotation anyway to mark an annotation as a constraint annotation

_________________
Emmanuel


Top
 Profile  
 
 Post subject: costume annotations
PostPosted: Thu Apr 03, 2008 3:06 pm 
Newbie

Joined: Thu Apr 03, 2008 2:25 pm
Posts: 1
Hello,

Will I be able to create a costume annotation not requiring writing a costume constraint, that i would be able to do something like:

AddressLine.java:
Code:
@Retention(RUNTIME)
@Target(FIELD)
@Min(20)
@Max(50)
@NotEmpty(message="{field} is mandatory")

public @interface AddressLine{}


Bean.java:
Code:
@AddressLine private String AddressLine1;


the idea is to have a composite annotation out of most simple already provided ones without having to write an implementation class for it as explained in your 2d blog post about the jsr.

Best Regards
Daoud AbdelMonem Faleh


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 5:07 pm 
Newbie

Joined: Mon Mar 31, 2008 12:05 pm
Posts: 11
emmanuel wrote:
rburton wrote:
OK, sorry about the mix up.

I hate to throw my 2 cents out there, but I tend to lean toward convention in this case. Grails shows how powerful convention over configuration can be. Instead of decorating a given annotation with yet another annotation, what about applying a naming convention.

E.g.,

@javax.validation.annotations.Nullable expects a class located javax.validation.annotations.NullableValidator that implements the JSR interface.


Because contrary to Grails we can use a plain type safe IDE that points us in one click to the implementation :)

Remember, Grails makes heavy uses of Convention over configuration (CoCo ? :) ) because:
- it had no real way to express metadata in the code (namely no annotation): annotation support in Groovy came later.
- they rely on a dynamic language

Anyway, we are talking about one line of code.


I totally agree that its just one line of code and nothing major. Convention over configuration I believe is powerful. It leans itself to being more productive by reducing the amount of configuration needed.

It people started to use CoCo :) over XML and other means of expressing configuration early on, frameworks wouldn't be so complex :)

Best Regard,
Richard L. Burton III


Top
 Profile  
 
 Post subject: Re: costume annotations
PostPosted: Thu Apr 03, 2008 7:08 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
Dao wrote:
Hello,

Will I be able to create a costume annotation not requiring writing a costume constraint, that i would be able to do something like:

AddressLine.java:
Code:
@Retention(RUNTIME)
@Target(FIELD)
@Min(20)
@Max(50)
@NotEmpty(message="{field} is mandatory")

public @interface AddressLine{}


Bean.java:
Code:
@AddressLine private String AddressLine1;


the idea is to have a composite annotation out of most simple already provided ones without having to write an implementation class for it as explained in your 2d blog post about the jsr.

Best Regards
Daoud AbdelMonem Faleh


The idea is very interesting, we started to explore the idea a little while ago in the group. The main concern is about parameters, what if I want to parameterize the meta annotations?

_________________
Emmanuel


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 15 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.