April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-267) Provide a ConstraintViolationException builder to facilitate consumer code

by Emmanuel Bernard (JIRA)

Provide a ConstraintViolationException builder to facilitate consumer code -------------------------------------------------------------------------- Key: BVAL-267 URL: https://hibernate.onjira.com/browse/BVAL-267 Project: Bean Validation Issue Type: Improvement Components: spec-general Reporter: Emmanuel Bernard -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-285) ValidatorFactory#close should clearly state post condidtions

by Hardy Ferentschik (JIRA)

ValidatorFactory#close should clearly state post condidtions ------------------------------------------------------------- Key: BVAL-285 URL: https://hibernate.onjira.com/browse/BVAL-285 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.1.next Reporter: Hardy Ferentschik The Javadocs for ValidatorFactory#close says: {quote} After the _ValidatorFactory_ instance is closed, it is not allowed to call: * methods of this _ValidatorFactory_ instance * methods of _Validator_ instances created by this _ValidatorFactory_ {quote} It does, however, not specified what happens if such a method is called. I think with this wording a post conditions needs to be specified, eg a _ValidationException_ will be thrown. Otherwise the docs should say that the behavior is unspecified if any of the mentioned methods is called after calling _close()_ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-7000) Avoid initializing proxy when using covariant return types for ID getters

by Michael Rudolf (JIRA)

Avoid initializing proxy when using covariant return types for ID getters ------------------------------------------------------------------------- Key: HHH-7000 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-7000 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Michael Rudolf When using an entity hierarchy with overridden ID getters and covariant return types, Hibernate does not detect ID getter calls and unnecessarily initializes proxies in order to call the methods instead of just returing the ID. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3502) getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type

by Sean Bridges (JIRA)

getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type ---------------------------------------------------------------------------------------------------------------------------- Key: HHH-3502 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3502 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Reporter: Sean Bridges Priority: Minor I have an entity interface, public interface IEntity { public Object getId(); } and I have an entity, say User that implements this interface with an id method @Id public Long getId() { return id; } I can call getId() on an uninitialized proxy with, user.getId() however, if I call getId() in this way, ((IEntity) user)).getId() I get org.hibernate.LazyInitializationException: could not initialize proxy - no Session Looking at the code, BasicLazyInitializer has these lines, else if ( isUninitialized() && method.equals(getIdentifierMethod) ) { return getIdentifier(); } the method.equals(getIdentifierMethod) returns false. The methods are not equal() because they have different return types (this is allowed in 1.5 with covariant return types). Hibernate should not use Method.equals(), but should instead use the code below (modified from Method.equals(Object)), public boolean equalsIgnoringReturnType(Method m1, Method m2) { if ((m1.getDeclaringClass() != m2.getDeclaringClass()) { return false; } if (m1.getName() != m2.getName()) { return false; } Class[] params1 = m1.getParameterTypes(); Class[] params2 = m2.getParameterTypes(); if (params1.length != params2.length) { return false; } for (int i = 0; i < params1.length; i++) { if (params1[i] != params2[i]) return false; } return true; } -- 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

11 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (JPA-12) Cannot use { in string literal of native SQL query

by Neil Buesing (JIRA)

Cannot use { in string literal of native SQL query -------------------------------------------------- Key: JPA-12 URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-12 Project: Java Persistence API Issue Type: Bug Affects Versions: 1.0.0 Environment: Hibernate 3.3.2.GA_CP01, Oracle 10g, Windows 32bit, Java 1.6 Reporter: Neil Buesing a JPA Native query will throw an exception if a { is within a string literal. Rejected Hibernate Defect: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2744 Exception: Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: Unmatched braces for alias path Query example (taken from HHH-2744) select count(distinct v.id) from some_table v left join other_table p on v.id = p.foreign_id where upper(v.last_name) like upper('{%'); No where do I find in the JPA specification that SQL queries can be limited; if the SQL is valid, it should be able to be parsed by the JPA Native Query support. I understand there is a work around, but it should be allowed. The {} balance check shouldn't count {} that are within string literals. -- 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

11 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2744) QueryException raised for valid SQL query - problems with aliases parsing

by Michal Jastak (JIRA)

QueryException raised for valid SQL query - problems with aliases parsing ------------------------------------------------------------------------- Key: HHH-2744 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2744 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.1 Environment: Tomcat 5.5, Hibernate Annotations 3.3.0 ga Reporter: Michal Jastak SQLQuery parser dose not parse queries correctly. Trying to invoke: session.createSQLQuery("select foo from bar where foo like '{%'"); ends with: rg.hibernate.QueryException: Unmatched braces for alias path [select foo from bar where foo like '{%'] at org.hibernate.loader.custom.sql.SQLQueryParser.substituteBrackets(SQLQueryParser.java:74) at org.hibernate.loader.custom.sql.SQLQueryParser.process(SQLQueryParser.java:51) at org.hibernate.loader.custom.sql.SQLCustomQuery.<init>(SQLCustomQuery.java:110) at org.hibernate.engine.query.NativeSQLQueryPlan.<init>(NativeSQLQueryPlan.java:43) at org.hibernate.engine.query.QueryPlanCache.getNativeSQLQueryPlan(QueryPlanCache.java:114) at org.hibernate.impl.AbstractSessionImpl.getNativeSQLQueryPlan(AbstractSessionImpl.java:137) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152) -- 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

11 years, 10 months

5
8
0 / 0

[Hibernate-JIRA] Created: (BVAL-283) Clarify that ConstraintValidator instances must be destroyed after each method validation call if the ConstraintValidatorFactory is provided to the Validator

by Emmanuel Bernard (JIRA)

Clarify that ConstraintValidator instances must be destroyed after each method validation call if the ConstraintValidatorFactory is provided to the Validator ------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: BVAL-283 URL: https://hibernate.onjira.com/browse/BVAL-283 Project: Bean Validation Issue Type: Bug Affects Versions: 1.1.0.Alpha1 (early draft 1) Reporter: Emmanuel Bernard Fix For: 1.1.next Validator validator = validatorFactory.usingContext().constraintValidatorFactory(otherCVF).getValidator() each method call for validator using ConstraintValidator instances must request then and release them as we won't have any close hook in Validator. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
5
0 / 0

[Hibernate-JIRA] Created: (BVAL-284) Clarify that ConstraintValidator instances passed to CVF.releaseInstance must be coming from the CVF creating them

by Emmanuel Bernard (JIRA)

Clarify that ConstraintValidator instances passed to CVF.releaseInstance must be coming from the CVF creating them ------------------------------------------------------------------------------------------------------------------ Key: BVAL-284 URL: https://hibernate.onjira.com/browse/BVAL-284 Project: Bean Validation Issue Type: Bug Affects Versions: 1.1.0.Alpha1 (early draft 1) Reporter: Emmanuel Bernard Fix For: 1.1.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-276) Consider a switch for adding a node representing the bean to property pathes

by Gunnar Morling (JIRA)

Consider a switch for adding a node representing the bean to property pathes ---------------------------------------------------------------------------- Key: BVAL-276 URL: https://hibernate.onjira.com/browse/BVAL-276 Project: Bean Validation Issue Type: Sub-task Reporter: Gunnar Morling In property pathes as returned by {{ConstraintViolation#getPropertyPath()}}, there is currently no node contained representing the root bean, if a property, method or constructor is traversed. We should consider to add such a node. In order to be compatible with the BV 1.0 behavior, we probably need some sort of switch for this. Related discussion by Emmanuel and Gunnar: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2012/... (starting 19:01:05). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-240) Revisit cross field validation

by Emmanuel Bernard (JIRA)

Revisit cross field validation ------------------------------ Key: BVAL-240 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-240 Project: Bean Validation Issue Type: Improvement Components: spec-general Reporter: Emmanuel Bernard Fix For: 1.1 Cross field validation is addressed via a black box model using class-level constraint validators. While conceptually elegant, many people have asked for a way to place such field validation at the field level and offer the ability to reach the value of another field from here. Cross field validation is also a need in presentation layers like JSF. Let's reopen the debate if time permits. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2012