[hibernate-issues] [Hibernate-JIRA] Updated: (BVAL-198) Simplify creation of ConstraintViolationExceptions

[Hardy Ferentschik (JIRA)]

     [ https://hibernate.onjira.com/browse/BVAL-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hardy Ferentschik updated BVAL-198:
-----------------------------------

    Description: 
_javax.validation.ConstraintViolationException_ wraps a set of constraint violations, currently in the following form:

{code}
Set<ConstraintViolation<?>> constraintViolations
{code}

As the exception's constructors have a parameter of the same type, instantiating it is not as easy as expected:

{code}
Validator validator = ...;
DomainObject domainObject = new DomainObject();
Set<ConstraintViolation<DomainObject>> constraintViolations = validator.validate(domainObject);

//compiler error: ("The constructor ConstraintViolationException(Set<ConstraintViolation<DomainObject>>) is undefined")
throw new ConstraintViolationException(constraintViolations);

//this works
throw new ConstraintViolationException(new HashSet<ConstraintViolation<?>>(constraintViolations));
{code}

This problem can be solved by changing the collection type to 

{code}
Set<? extends ConstraintViolation<?>>
{code}

The exception then would read as follows:

{code}
public class ConstraintViolationException extends ValidationException {
	private final Set<? extends ConstraintViolation<?>> constraintViolations;

	public ConstraintViolationException(String message, Set<? extends ConstraintViolation<?>> constraintViolations) {
		super( message );
		this.constraintViolations = constraintViolations;
	}

	public ConstraintViolationException(Set<? extends ConstraintViolation<?>> constraintViolations) {
		super();
		this.constraintViolations = constraintViolations;
	}

	public Set<ConstraintViolation<?>> getConstraintViolations() {
		return new HashSet<ConstraintViolation<?>>(constraintViolations);
	}
}
{code}

This makes the exception easier to use for producers, while maintaining simplicity for clients (since _getConstraintViolations()_ still returns a _Set<ConstraintViolation<?>>_, clients don't have to do deal with the bound wildcard expression).

  was:
javax.validation.ConstraintViolationException wraps a set of constraint violations, currently in the following form:

Set<ConstraintViolation<?>> constraintViolations

As the exception's constructors have a parameter of the same type, instantiating it is not as easy as expected:

Validator validator = ...;
DomainObject domainObject = new DomainObject();
Set<ConstraintViolation<DomainObject>> constraintViolations = validator.validate(domainObject);

//compiler error: ("The constructor ConstraintViolationException(Set<ConstraintViolation<DomainObject>>) is undefined")
throw new ConstraintViolationException(constraintViolations);

//this works
throw new ConstraintViolationException(new HashSet<ConstraintViolation<?>>(constraintViolations));

This problem can be solved by changing the collection type to 

Set<? extends ConstraintViolation<?>>

The exception then would read as follows:

public class ConstraintViolationException extends ValidationException {
	private final Set<? extends ConstraintViolation<?>> constraintViolations;

	public ConstraintViolationException(String message, Set<? extends ConstraintViolation<?>> constraintViolations) {
		super( message );
		this.constraintViolations = constraintViolations;
	}

	public ConstraintViolationException(Set<? extends ConstraintViolation<?>> constraintViolations) {
		super();
		this.constraintViolations = constraintViolations;
	}

	public Set<ConstraintViolation<?>> getConstraintViolations() {
		return new HashSet<ConstraintViolation<?>>(constraintViolations);
	}
}

This makes the exception easier to use for producers, while maintaining simplicity for clients (since getConstraintViolations() still returns a Set<ConstraintViolation<?>>, clients don't have to do deal with the bound wildcard expression).


> Simplify creation of ConstraintViolationExceptions
> --------------------------------------------------
>
>                 Key: BVAL-198
>                 URL: https://hibernate.onjira.com/browse/BVAL-198
>             Project: Bean Validation
>          Issue Type: Improvement
>          Components: spec-general
>    Affects Versions: 1.0 final
>            Reporter: Gunnar Morling
>         Attachments: bval-198.diff
>
>
> _javax.validation.ConstraintViolationException_ wraps a set of constraint violations, currently in the following form:
> {code}
> Set<ConstraintViolation<?>> constraintViolations
> {code}
> As the exception's constructors have a parameter of the same type, instantiating it is not as easy as expected:
> {code}
> Validator validator = ...;
> DomainObject domainObject = new DomainObject();
> Set<ConstraintViolation<DomainObject>> constraintViolations = validator.validate(domainObject);
> //compiler error: ("The constructor ConstraintViolationException(Set<ConstraintViolation<DomainObject>>) is undefined")
> throw new ConstraintViolationException(constraintViolations);
> //this works
> throw new ConstraintViolationException(new HashSet<ConstraintViolation<?>>(constraintViolations));
> {code}
> This problem can be solved by changing the collection type to 
> {code}
> Set<? extends ConstraintViolation<?>>
> {code}
> The exception then would read as follows:
> {code}
> public class ConstraintViolationException extends ValidationException {
> 	private final Set<? extends ConstraintViolation<?>> constraintViolations;
> 	public ConstraintViolationException(String message, Set<? extends ConstraintViolation<?>> constraintViolations) {
> 		super( message );
> 		this.constraintViolations = constraintViolations;
> 	}
> 	public ConstraintViolationException(Set<? extends ConstraintViolation<?>> constraintViolations) {
> 		super();
> 		this.constraintViolations = constraintViolations;
> 	}
> 	public Set<ConstraintViolation<?>> getConstraintViolations() {
> 		return new HashSet<ConstraintViolation<?>>(constraintViolations);
> 	}
> }
> {code}
> This makes the exception easier to use for producers, while maintaining simplicity for clients (since _getConstraintViolations()_ still returns a _Set<ConstraintViolation<?>>_, clients don't have to do deal with the bound wildcard expression).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira