March 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HV-455) Verify in the annotation processor that the groups parameter in a constraint declaration contains only interfaces

by Kevin Pollet (JIRA)

Verify in the annotation processor that the groups parameter in a constraint declaration contains only interfaces ----------------------------------------------------------------------------------------------------------------- Key: HV-455 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-455 Project: Hibernate Validator Issue Type: New Feature Components: annotation-processor Reporter: Kevin Pollet Fix For: 4.x When a constraint is defined, it's possible to specify the groups it belongs. The section 3.5 of the specification says: {{quote}}Groups are represented by interfaces.{{quote}} Consequently, the annotation processor should check that only interfaces are used in the {{groups}} parameter of a constraint declaration. -- 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

14 years

2
4
0 / 0

[Hibernate-JIRA] Created: (HV-308) Annotation processor should consider validators registered by XML constraint mapping

by Gunnar Morling (JIRA)

Annotation processor should consider validators registered by XML constraint mapping ------------------------------------------------------------------------------------ Key: HV-308 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-308 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Reporter: Gunnar Morling Assignee: Hardy Ferentschik Fix For: 4.1.0 Background: The Bean Validation API allows the set of validators for a given constraint to be specified/overridden using XML constraint mapping files (http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single...). Right now the annotation processor does not process any XML configuration files at all (neither validation.xml nor mapping files). To do: While it seems ok for now that the AP does not check constraint declarations given in XML (after all it's an *annotation* processor), I think it should evaluate the constraint definitions and the validators configured in XML. Otherwise the AP would raise false errors (as validators added in XML are ignored) or would give false positives (as validators given in @Constraint#validatedBy could be removed by "include-existing-validator='false'"). -- 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

14 years

2
8
0 / 0

[Hibernate-JIRA] Created: (HV-450) The annotation processor should check parameter constraints

by Gunnar Morling (JIRA)

The annotation processor should check parameter constraints ----------------------------------------------------------- Key: HV-450 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-450 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Reporter: Gunnar Morling Fix For: 4.x The AP should have support for method parameter constraints. We should definitely check the parameter types as we already do for any other constraints. Additionally we might check that preconditions are not strengthened in sub-types (see HV-421), though I'd regard this as add-on. -- 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

14 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-432) Create a Java agent to enfore method level validation (design by contract)

by Hardy Ferentschik (JIRA)

Create a Java agent to enfore method level validation (design by contract) -------------------------------------------------------------------------- Key: HV-432 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-432 Project: Hibernate Validator Issue Type: Task Components: engine Affects Versions: 4.2.0.Final Reporter: Hardy Ferentschik Fix For: 4.x Google released Contract for Java - http://code.google.com/p/cofoja/ - which is a Java implementations for Design by Contract. Googles version uses a set of annotations, an annotation processor and a runtime java agent (see their documentation). We have all the pieces for doing this as well. * We have the constraint annotations * We have an annotation processor (obviously it does something else now, but we know how to write one) * And we have Byteman I wonder whether we couldn't put these things together and create our own Contract for Java. -- 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

14 years

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-388) Support property level ScriptAssert

by jason shi (JIRA)

Support property level ScriptAssert ----------------------------------- Key: HV-388 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-388 Project: Hibernate Validator Issue Type: New Feature Components: engine Affects Versions: 4.1.0.Final Reporter: jason shi Assignee: Hardy Ferentschik Current hibernate validator's ScriptAssert can only defined on the Class level, not property level. In OVal,it can define the ScriptAssert at the property level,eg: {code} public class BusinessObject { @NotNull public String deliveryAddress; @NotNull public String invoiceAddress; // mailingAddress must either be the delivery address or the invoice address @Assert(expr = "_value ==_this.deliveryAddress || _value == _this.invoiceAddress", lang = "groovy") public String mailingAddress; } {code} With property level,we can get following benefit: 1. Can be used in single property validation, It's very useful in UI layer validation 2. The validation rule is close to the property definition, it's easy to manage In JSR303 spec, the ValueContext is not passed to the Contrain Validator as a parameter, so the validator can't get the "Current Bean" of the current property to be validated. The validation engine need to some special work to support this feature. OVal can do this, so it won't be a problem for hibernate validator. -- 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

14 years

4
6
0 / 0

[Hibernate-JIRA] Created: (HV-451) The annotation processor should check @GroupSequence

by Kevin Pollet (JIRA)

The annotation processor should check @GroupSequence ---------------------------------------------------- Key: HV-451 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-451 Project: Hibernate Validator Issue Type: New Feature Components: annotation-processor Reporter: Kevin Pollet Fix For: 4.x The AP should check that the {{GroupSequence}} definition is valid. For example, the AP could check that: * the class list contains the hosting bean class (for default group sequence re-definition) * the class list contains only interface * the defined group sequence is expandable (no cyclic definition) * ... -- 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

14 years

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-22) Dynamic metadata mode

by Emmanuel Bernard (JIRA)

Dynamic metadata mode --------------------- Key: BVAL-22 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-22 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Priority: Minor Test how a dynamic reloading mode would work. Instead of caching metadata by ValidationFactory, reload as the data might have changed (annotations or XML) This can be a configuration setting. -- 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

14 years

2
9
0 / 0

[Hibernate-JIRA] Created: (BVAL-44) Explore integration with Bean Validation APIs and a Rule engine

by Emmanuel Bernard (JIRA)

Explore integration with Bean Validation APIs and a Rule engine --------------------------------------------------------------- Key: BVAL-44 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-44 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Priority: Minor http://forum.hibernate.org/viewtopic.php?t=991847 If possible community driven. -- 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

14 years

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-356) Consider if issue when bean's hashCode() uses lazy-loaded property needs to be addressed in default event listener/validator implementation

by Roman Arkadijovych Muntyanu (JIRA)

Consider if issue when bean's hashCode() uses lazy-loaded property needs to be addressed in default event listener/validator implementation ------------------------------------------------------------------------------------------------------------------------------------------- Key: HV-356 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-356 Project: Hibernate Validator Issue Type: Task Components: validators Affects Versions: 4.1.0.Final Environment: Hibernate 3.5.3-Final, Spring 3.0.3.RELEASE, Hibernate Validator 4.1.0.Final Reporter: Roman Arkadijovych Muntyanu Assignee: Hardy Ferentschik Priority: Minor This issue has been created based on contributor's request in discussion https://forum.hibernate.org/viewtopic.php?f=9&t=1006194&start=0 related to the issue occurring when persisted object's hashCode() implementation uses lazily-loaded properties. This triggers "collection [...] was not processed by flush()" issue with default Hibernate Validator event listener (org.hibernate.cfg.beanvalidation.BeanValidationEventListener) and validator (org.hibernate.validator.engine.ValidatorImpl) implementations because of hashCode() usage in SingleThreadCachedTraversableResolver.buildHashCode(). The purpose of this task is to consider whether this is or is not an overlook in assumptions made in validator implementation. And depending on the result following outcomes are expected: * either create a separate task for addressing the issue in default validator implementation; * or provide suggestions and (if possible) examples on how the issue can be addressed at the framework user's site if lazily-loaded properties usage IS appropriate. -- 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

14 years

2
6
0 / 0

[Hibernate-JIRA] Created: (BVAL-189) Bean Validation should use java.beans.PropertyDescriptor

by Brian (JIRA)

Bean Validation should use java.beans.PropertyDescriptor -------------------------------------------------------- Key: BVAL-189 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-189 Project: Bean Validation Issue Type: Bug Affects Versions: 4.0.0.Alpha1 Environment: Any Reporter: Brian Priority: Minor Right now, hibernate determines a matching getter and setters by matching methods that start with "get" and "set" or "is" and "set". But the spec says that "is" should only be considered when the type is little boolean. Hibernate should fail validation in this case because it doesn't match the spec: public Boolean isVariable() public Boolean setVariable() because in this case "is" should be "get" since it is not a little boolean. -- 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

14 years

3
5
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 March 2012