February 2013 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] (BVTCK-34) Investigate whether character escaping can be avoided in tck-audit.xml

by Gunnar Morling (JIRA)

13 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] (HV-673) JPATraversableResolver must handle method parameters when invoked during method validation

by Gunnar Morling (JIRA)

13 years, 1 month

2
6
0 / 0

[Hibernate-JIRA] (HV-675) Method return values must not be marked with @Valid if the super-type/interface method is marked

by Gunnar Morling (JIRA)

13 years, 1 month

2
4
0 / 0

[Hibernate-JIRA] (HV-657) Remove tests in BeanMetaDataImplTest

by Hardy Ferentschik (JIRA)

13 years, 1 month

2
3
0 / 0

[Hibernate-JIRA] (HV-664) Path nodes representing executable return values must return null as name

by Gunnar Morling (JIRA)

13 years, 1 month

2
7
0 / 0

[Hibernate-JIRA] (HV-695) CDI extension throws exception due to calling BeanManager#getBeans during AfterBeanDiscovery event processing

by Hardy Ferentschik (JIRA)

13 years, 1 month

2
4
0 / 0

[Hibernate-JIRA] (HV-685) The tck runner setup fails to run in container

by Hardy Ferentschik (JIRA)

13 years, 1 month

1
4
0 / 0

[Hibernate-JIRA] (HV-660) BeanDescriptor#getConstrainedProperties() must return no elements for class-level constraints

by Gunnar Morling (JIRA)

13 years, 1 month

2
3
0 / 0

[Hibernate-JIRA] (HV-662) ConstraintValidatorManager caching fails for XML-defined constraints

by Craig Leonard (JIRA)

13 years, 1 month

3
8
0 / 0

[Hibernate-JIRA] Created: (HV-409) Provide the possibility to specify parameter names for reporting method level constraint violations

by Gunnar Morling (JIRA)

Provide the possibility to specify parameter names for reporting method level constraint violations --------------------------------------------------------------------------------------------------- Key: HV-409 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-409 Project: Hibernate Validator Issue Type: New Feature Components: engine Reporter: Gunnar Morling When reporting a method level constraint violation besides the concerned method the parameter causing the violation is a substantial information. As the Java byte code usually doesn't contain any information on parameter names only the index of the parameter can be returned in the resulting MethodConstraintViolation. In order to produce expressive constraint violations it is desirable to have the possibility to specify parameter names in some way. One approach for this might be to allow parameter names being specified with the help of an appropriate annotation. Using JSR 330's @Named annotation for instance this could look like this: {code:java} someMethod(@Named("param1") @NotNull String param1, @Named("customer") @NotNull @Valid Customer customer) { //... } {code} In case any of the method's constraints is violated the resulting MethodConstraintViolation would refer to this name in getName() and getPropertyPath(): {code:java} assertEquals( constraintViolation.getParameterName(), "customer" ); assertEquals( constraintViolation.getPropertyPath().toString(), "SomeType#someMethod(customer).name" ); {code} This approach was prototyped in https://github.com/gunnarmorling/hibernate-validator/commits/method-level... but was removed for HV 4.2 with [e7e3c5f6e97d850b65579fc542599d4c9241048d|https://github.com/gunnarmorling...] and [8fbc2cca1481563309a03f58ccb4037134772801|https://github.com/gunnarmorling...] to have time for some more considerations. In especially an algorithm for retrieving the effective name of a method parameter has to be defined. This might look like this: * If the validated method doesn't override any method from a super type the parameter names are taken from this method (if given) * If the validated method does override a method from a super type, the closest names found up in the inheritance tree are taken (e.g. when validating A#foo() overriding B#foo() in turn overriding C#foo() and both B and C provide parameter names for foo(), then the names from B#foo() are taken) * If the name for a parameter is given in two or more equally distant types, the names of any from the closest types are taken, from which of this is not defined (e.g. when validating A#foo() implementing B#foo() and C#foo() and both B and C specify parameter names for foo(), the names either from B or C are taken) When implementing this feature HV should not require new strict dependencies; so if for instance working with @Named, javax.inject-1.jar should be added in optional scope and the type javax.inject.Named should be accessed only using reflection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2013