August 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-222) Add a ALL group to validate all groups instead of DEFAULT or the selected ones

by Emmanuel Bernard (JIRA)

Add a ALL group to validate all groups instead of DEFAULT or the selected ones ------------------------------------------------------------------------------ Key: BVAL-222 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-222 Project: Bean Validation Issue Type: New Feature Components: spec-general Reporter: Emmanuel Bernard Gerhard #2 it would be nice to have #validateAll or a group called javax.validation.groups.All to validate all groups without knowing the concrete groups. Emmanuel What's the use case they were invoking? ( my favorite mantra :) ) Gerhard i think it was just: if you are using groups for partial validation you might have a wizard and in every step you validate with a different group and they needed the concept instead of collecting all groups manually (e.g. in the service which finally saves the new entry) -> they requested an api for validating every constraint which is available in the given object-graph -> the service can perform a full validation before it processes the data. -- 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, 2 months

1
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-234) Netbeans 7 default generated entity classes conflict with bean validation

by Richard Clarke (JIRA)

Netbeans 7 default generated entity classes conflict with bean validation -------------------------------------------------------------------------- Key: BVAL-234 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-234 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.1 Environment: Netbeans 7, Seam 3 under JBOSS AS 7 Reporter: Richard Clarke Priority: Minor When using NetBeans 7 to generate entity classes from a database table, the entity classes are generated with the following annotations... public class Orders implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Basic(optional = false) @NotNull @Column(name = "orderid") private Integer orderid; ..... When persisting, bean validation fails because the autogenerated primary key is null at the time the object is persisted. Netbeans have stated that they wont fix this as they see it as bean validation issue rather than their generated classes. See here: http://netbeans.org/bugzilla/show_bug.cgi?id=197845 Related Forum posting is here... https://forum.hibernate.org/viewtopic.php?f=9&t=1011908 Suggest modifying Bean Validation Pre-Persist to ignore @NotNull if @GeneratedValue exists. Thanks Rich -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

4
9
0 / 0

[Hibernate-JIRA] Created: (HV-462) Allow ordered validator's annotations

by Pavla Nováková (JIRA)

Allow ordered validator's annotations ------------------------------------- Key: HV-462 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-462 Project: Hibernate Validator Issue Type: New Feature Affects Versions: 4.1.0.Final Reporter: Pavla Nováková 1) Consider domain object with simple constraints (just to demonstrate required feature, my real example uses custom cost-expensive validation of pictures): {code} public class DomainObject { @Size(max=50) // constraint 1a @Pattern(regexp="[a-z]*") // constraint 1b private String name; @Size(max=20) // constraint 2a @URL // constraint 2b private String email; @Size(max=100) // constraint 3a @Pattern(regexp="[0-9]*") // constraint 3b private String password; {code} 2) Consider validation requirements: * all properties should be validated together (like one virtual group) * FOR EACH PROPERTY validation should occur in ordered steps given by order of annotations for given property (if first validation step fails, SKIP following validation process on given property and add validation message specific to failed / last validated constraint for the property) 3) Why it is useful: * simple cost-effective validation followed by cost-expensive validation (not executed if simple constraint fails) * we get just the "main and specific validation error" (otherwise we have to iterate over all errors "to find the cause" or we display two or more errors for one property which is not user-friendly according my opinion) 3) What is unusable: * groups and group sequences (it is not possible to create proper combination of groups and sequences for more than one property with two or more constraints) * composed constraints (@ReportAsSingleViolation included) ** we cannot use @ReportAsSingleViolation since we want specific message for each failed constraint ** and main problem is: if we use composed constraints all constraints are evaluated for given property 4) Proposed solution: * add optional order attribute to validator annotations and stop validation on first failure if order is specified * possibly this can be configured on global validator level with property "skipOnFirstFailure" together with some given convention for annotation order Please let me know if need better explanation or working examples. -- 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, 2 months

3
8
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, 2 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, 2 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, 2 months

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5704) New getSubString() handling in ClobProxy is incompatible with MySQL JDBC PS.setClob(int, Clob) for empty CLOB

by Sergey Vladimirov (JIRA)

New getSubString() handling in ClobProxy is incompatible with MySQL JDBC PS.setClob(int, Clob) for empty CLOB ------------------------------------------------------------------------------------------------------------- Key: HHH-5704 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5704 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.0 Environment: MySQL JDBC 5.1.12 / 5.1.13 Reporter: Sergey Vladimirov For all empty but not-null CLOBs MySQL drivers do the following (com.mysql.jdbc.PreparedStatement): String forcedEncoding = this.connection.getClobCharacterEncoding(); if (forcedEncoding == null) { setString(i, x.getSubString(1L, (int) x.length())); } else { try { setBytes(i, x.getSubString(1L, (int)x.length()).getBytes(forcedEncoding)); } catch (UnsupportedEncodingException uee) { throw SQLError.createSQLException("Unsupported character encoding " + forcedEncoding, SQLError.SQL_STATE_ILLEGAL_ARGUMENT, getExceptionInterceptor()); } } As you can see, getSubString is called with first argument (start) equal to 1, even if length of CLOB is 0. Of course, it's not very good, but it worked for previous versions of Hibernate. But in 3.6.0 getSubString() handling in ClobProxy introduces additional checks that prevents the code above from working: if ( start > getLength() ) { throw new SQLException( "Start position [" + start + "] cannot exceed overall CLOB length [" + getLength() + "]" ); } Thus this code will now thrown an exception if content is empty (but not null!) CLOB. Here the part of stack trace: 31.10 16:46:03 .AbstractFlushingEventListener ERROR Could not synchronize database state with session org.hibernate.exception.GenericJDBCException: could not insert: [ru.arptek.classes.dummy.Article$Content] at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:140) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:128) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2436) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2856) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:184) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:795) at ru.arptek.arpsite.content.WebObjectHome.create(WebObjectHome.java:122) (...) Caused by: java.sql.SQLException: Start position [1] cannot exceed overall CLOB length [0] at org.hibernate.engine.jdbc.ClobProxy.invoke(ClobProxy.java:146) at $Proxy52.getSubString(Unknown Source) at com.mysql.jdbc.PreparedStatement.setClob(PreparedStatement.java:3542) at com.mysql.jdbc.jdbc2.optional.PreparedStatementWrapper.setClob(PreparedStatementWrapper.java:299) at org.apache.commons.dbcp.DelegatingPreparedStatement.setClob(DelegatingPreparedStatement.java:187) at org.apache.commons.dbcp.DelegatingPreparedStatement.setClob(DelegatingPreparedStatement.java:187) at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$1.doBind(ClobTypeDescriptor.java:60) at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:89) at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:282) at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:277) at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:85) at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2166) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2412) ... 70 more I believe there should be additional check like: long start = (Long) args[0]; if ( start < 1 ) { throw new SQLException( "Start position 1-based; must be 1 or more." ); } int length = (Integer) args[1]; if ( length < 0 ) { throw new SQLException( "Length must be great-than-or-equal to zero." ); } // workaround for MySQL incompatibility if ( start == 1 && length == 0) { return ""; } else if ( start > getLength() ) { throw new SQLException( "Start position [" + start + "] cannot exceed overall CLOB length [" + getLength() + "]" ); } return getSubString( start-1, length ); -- 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, 2 months

11
20
0 / 0

[Hibernate-JIRA] Created: (HHH-3826) Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server)

by Charles Moulliard (JIRA)

Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server) --------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3826 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3826 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Reporter: Charles Moulliard Hi, I try to use Hibernate 3.3.1.GA in combination with Spring OSGI 1.2.0-rc1. Unfortunately, there is a classloading issue on OSGI : {code} Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:162) ... 58 more Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167) at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170) ... 59 more Caused by: java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159) ... 60 more {code} remark : the package org.hibernate.proxy is defined in the MANIFEST file (section - Import-PAckage) -- 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, 2 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6165) HqlLexer can cause ClassNotFound in OSGi environment

by Jonathan Calvert (JIRA)

HqlLexer can cause ClassNotFound in OSGi environment ---------------------------------------------------- Key: HHH-6165 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6165 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.6.2, 3.6.1, 3.6.0, 3.6.0.CR2, 3.6.0.CR1, 3.5.6, 3.6.0.Beta4, 3.6.0.Beta3, 3.5.5, 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5.0-Final, 3.5.0-CR-2, 3.5.0-CR-1, 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2, 3.5.0.Beta-1, 3.3.2 Environment: At least from 3.3.2 on, and at least on Postgres and Derby Reporter: Jonathan Calvert Priority: Minor Attachments: hqllexer.patch org.hibernate.hql.ast.HqlLexer can cause a ClassNotFound exception in an OSGi environment with a stacktrace like {code} org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.ast.HqlToken [hql query here] at org.hibernate.hql.ast.HqlLexer.panic(HqlLexer.java:80) at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338) at org.hibernate.hql.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:54) ... {code} The HqlLexer class has antlr.CharScanner as a superclass, as evidenced by the stacktrace. The contents of the method are: {code} public void setTokenObjectClass(String cl) { // Ignore the token class name parameter, and use a specific token class. super.setTokenObjectClass( HqlToken.class.getName() ); } {code} It passes the name of the HqlToken class as a string to CharScanner, which then ultimately attempts to find HqlToken via antlr.Utils. The tokenObjectClass is a protected field. The code can be simplified by simply setting the field directly to HqlToken.class which is obviously already available to the HqlLexer class. The reason this causes the exception in an OSGi environment is that the context class loader available to ANTLR is limited to what is explicitly declared in the ANTLR bundle. Since ANTLR cannot (and should not) have to know about all the classes that it may be passed, it does not declare an import on the org.hibernate.hql.ast package. By passing the class directly, the lookup is avoided from within the ANTLR package. {code} public void setTokenObjectClass(String cl) { // Ignore the token class name parameter, and use a specific token class. tokenObjectClass = HqlToken.class; } {code} -- 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, 2 months

3
5
0 / 0

[Hibernate-JIRA] Created: (BVAL-191) Introduce a addEntityNode() method to the fluent node builder API

by Emmanuel Bernard (JIRA)

Introduce a addEntityNode() method to the fluent node builder API ----------------------------------------------------------------- Key: BVAL-191 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-191 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.0 final Reporter: Emmanuel Bernard In the current, model, to represent "persons[0]", we need to do constraintValidatorContext .buildConstraintViolationWithTemplate("constraints.CompatiblePersons.gender.message") .addNode("persons") .addNode(null).inIterable().atIndex(0) .addConstraintViolation(); this could be made cleaner with constraintValidatorContext .buildConstraintViolationWithTemplate("constraints.CompatiblePersons.gender.message") .addNode("persons") .addEntityNode().inIterable().atIndex(0) .addConstraintViolation(); -- 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, 2 months

3
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2011