March 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-282) Make clear whether it's legal to invoke Configuration#buildValidatorFactory() several times

by Gunnar Morling (JIRA)

Make clear whether it's legal to invoke Configuration#buildValidatorFactory() several times ------------------------------------------------------------------------------------------- Key: BVAL-282 URL: https://hibernate.onjira.com/browse/BVAL-282 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.0 final Reporter: Gunnar Morling Fix For: 1.1 It's currently not clearly specified, whether {{buildValidatorFactory()}} may be invoked several times on a given {{Configuration}} instance. A use case for this might be to create several factories which only slightly differ in their configuration: {code} Configuration<?> configuration = Validation.byDefaultProvider().configure(); //set up interpolator, traversable resolver etc. configuration. ...(); ValidatorFactory vf1 = configuration.buildValidatorFactory(); //further customize configuration for another factory configuration. ...(); ValidatorFactory vf2 = configuration.buildValidatorFactory(); {code} We should explicitly mention whether that's allowed or not. Related discussion on the mailing list: http://lists.jboss.org/pipermail/beanvalidation-dev/2012-March/000290.html Related post in HV forum: https://forum.hibernate.org/viewtopic.php?f=9&t=1014788 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
6
0 / 0

[Hibernate-JIRA] Created: (BVAL-271) Publish draft documents on beanvalidation.org

by Gunnar Morling (JIRA)

Publish draft documents on beanvalidation.org --------------------------------------------- Key: BVAL-271 URL: https://hibernate.onjira.com/browse/BVAL-271 Project: Bean Validation Issue Type: Task Components: spec-general Reporter: Gunnar Morling Assignee: Emmanuel Bernard As dicussed with Emmanuel via mail it would be great if we could publish draft documents and possibly also work-in-progress versions of the spec on beanvalidation.org to facilitate reviews by EG members and the public. Possible URLs: * http://beanvalidation.org/1.1/spec/drafts/1.1.Beta1 - the first "official" draft document will go here * http://beanvalidation.org/1.1/spec/preview/method-validation/latest - the current work-in-progress document of the method-validation work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-198) Simplify creation of ConstraintViolationExceptions

by Gunnar Morling (JIRA)

Simplify creation of ConstraintViolationExceptions -------------------------------------------------- Key: BVAL-198 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-198 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.1 Reporter: Gunnar Morling 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). -- 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, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-6127) Wrong save or read unicode value on @Lob String field in PostgreSQL 8.4

by Mihail Slobodyanuk (JIRA)

Wrong save or read unicode value on @Lob String field in PostgreSQL 8.4 ----------------------------------------------------------------------- Key: HHH-6127 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6127 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.3 Environment: PostgreSQL 8.4.5 on Ubuntu 32, Hibernate 3.6.0 - 3.6.3, jdbc driver: postgresql-8.3-603.jdbc3 Reporter: Mihail Slobodyanuk Priority: Critical <hibernate-configuration> <session-factory> <property name="hibernate.connection.driver_class">org.postgresql.Driver</property> <property name="hibernate.connection.url">jdbc:postgresql://localhost/test</property> <property name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</property> <property name="hibernate.connection.username">postgres</property> <property name="hibernate.connection.password">postgres</property> <property name="hbm2ddl.auto">update</property> <property name="hibernate.connection.charSet">UTF-8</property> <property name="hibernate.show_sql">true</property> <property name="hibernate.current_session_context_class">thread</property> </session-factory> </hibernate-configuration> @Entity public class ReportTemplate{ @Id @GeneratedValue private Integer id; @Lob private String body; ... } At save (or at read) operation with 'body' field value is broken. In DB stored Blob's OID. The next code throw AssertionError: String str="Русский текст";//Unicode string rt = new ReportTemplate(); rt.setBody(str); Serializable id = hsm.getSession().save(rt); hsm.commit(); hsm.getSession().clear(); rt = (ReportTemplate) hsm.getSession().get(ReportTemplate.class, id); assert str.equals(rt.getBody()); -- 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, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6075) registerVarcharTypes in MySQL5Dialect creates varchar for up to a length of 65535

by Thomas Einwaller (JIRA)

registerVarcharTypes in MySQL5Dialect creates varchar for up to a length of 65535 ---------------------------------------------------------------------------------- Key: HHH-6075 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6075 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: MySQL 5.1.52 Reporter: Thomas Einwaller while the registerVarcharTypes in the MySQLDialect only creates varchar columns with a length up to 255 seems like a regression caused by this commit: https://github.com/hibernate/hibernate-core/commit/d8d6d82e30960e0c255950... MySQL throws the following error: Error Code: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs when trying to create a table with 3 varchar (20000) colums -- 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, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3606) Can't use distinct in Oracle with BLOB/CLOB column

by Julien HENRY (JIRA)

Can't use distinct in Oracle with BLOB/CLOB column -------------------------------------------------- Key: HHH-3606 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3606 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: Oracle 9i Reporter: Julien HENRY Problem: Oracle doesn't support distinct when a row is BLOB/CLOB. The resulting error is: ORA-00932: inconsistent datatypes: expected - got CLOB I got this error when trying to filter root entity (see FAQ: http://www.hibernate.org/117.html#A12). It is not really an Hibernate bug, much likely an Oracle limitation. But perhaps an entry may be added in the FAQ, or perhaps some workaround may be found to not use SQL distinct keyword when a BLOB/CLOB is involved in the query. Some related links: http://drupal.org/node/48435 (FR) http://www.developpez.net/forums/d553106/java/general-java/persistance/hi... http://www.dbasupport.com/forums/showthread.php?t=46785 (possible rewriting of the query) -- 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, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2969) DB2Dialect Clob SchemaExport uses default length even if no length set

by Philippe Mouawad (JIRA)

DB2Dialect Clob SchemaExport uses default length even if no length set ---------------------------------------------------------------------- Key: HHH-2969 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2969 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, DB2 8, DB2 9 Reporter: Philippe Mouawad Attachments: db2-clob-schemaExport-patch.txt I have this property in my mapping: <property name="argumentsValues" column="cte_arguments_values" type="text" not-null="true" /> Notice no length is set. Hibernate schema Export generates: cte_arguments_names clob(255) not null, Same problem occurs for Clob and Blob. This is due to the following lines in org.hibernate.dialect.DB2Dialect: registerColumnType( Types.BLOB, "blob($l)" ); registerColumnType( Types.CLOB, "clob($l)" ); Attached is the patch. There would be another solution to test that Column has no length set. Philippe. www.ubik-ingenierie.com -- 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, 4 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HV-399) Make allowOneValidationPerPath in ValidationContext a configurable option

by Hardy Ferentschik (JIRA)

Make allowOneValidationPerPath in ValidationContext a configurable option ------------------------------------------------------------------------- Key: HV-399 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-399 Project: Hibernate Validator Issue Type: New Feature Components: engine Affects Versions: 4.1.0.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0.Beta1 Currently this option is hard-wired to be _true_ to align with the spec. Making it configurable will be a Hibernate Validator specific feature. -- 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, 4 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5971) Bad performance UpdateTimestampsCache ReentrantReadWriteLock

by Fernando Paris (JIRA)

Bad performance UpdateTimestampsCache ReentrantReadWriteLock ------------------------------------------------------------ Key: HHH-5971 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5971 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.1 Environment: hibernate 3.6.1, jboss as eap 4.3 Reporter: Fernando Paris Priority: Critical Performance bootleneck created by UpdateTimestampsCache invalidate, generating full heap. On the threaddump have 346 threads waiting for "ajp-0.0.0.0-5490-251" daemon prio=10 tid=0x00002aabc683c000 nid=0x7673 waiting on condition [0x000000005b4da000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00002aaac1c8c9d0> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:807) at org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:88) at org.hibernate.engine.ActionQueue$AfterTransactionCompletionProcessQueue.afterTransactionCompletion(ActionQueue.java:604) at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:209) at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:602) at org.hibernate.jdbc.JDBCContext.afterNontransactionalQuery(JDBCContext.java:292) at org.hibernate.impl.SessionImpl.afterOperation(SessionImpl.java:595) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1273) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102) at org.springframework.orm.hibernate3.HibernateTemplate$34.doInHibernate(HibernateTemplate.java:1024) at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419) at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) at org.springframework.orm.hibernate3.HibernateTemplate.findByNamedQueryAndNamedParam(HibernateTemplate.java:1015) at com.rumbo.hotel.dbaccess.dao.impl.DhotMetadataDAOImpl.getByDescriptionKey(DhotMetadataDAOImpl.java:46) at com.rumbo.alojamientos.tools.parameter.HotelParameterCacheManager.getParameter(HotelParameterCacheManager.java:113) at com.rumbo.alojamientos.tools.parameter.HotelParameterCacheManager.getParameterValue(HotelParameterCacheManager.java:76) at com.rumbo.alojamientos.tools.parameter.HotelParameterCacheManager.getParameterValue(HotelParameterCacheManager.java:87) at com.rumbo.alojamientos.tools.logging.LoggingUtilities.isLogWritingActive(LoggingUtilities.java:189) at com.rumbo.alojamientos.tools.logging.LoggingUtilities.isLogWritingActive(LoggingUtilities.java:232) at com.rumbo.alojamientos.tools.logging.LoggingUtilities.saveLog(LoggingUtilities.java:141) at com.rumbo.hoteles.ws.interceptor.LoggingInterceptor.saveLog(LoggingInterceptor.java:168) at com.rumbo.hoteles.ws.interceptor.LoggingInterceptor.handleRequest(LoggingInterceptor.java:94) at org.springframework.ws.server.MessageDispatcher.dispatch(MessageDispatcher.java:213) at org.springframework.ws.server.MessageDispatcher.receive(MessageDispatcher.java:168) at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:88) at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57) at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:230) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.rumbo.mvc.encoding.EncodingFilter.doFilter(EncodingFilter.java:61) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437) at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) -- 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, 4 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-6396) Remove org.hibernate.annotations.Entity

by Steve Ebersole (JIRA)

Remove org.hibernate.annotations.Entity --------------------------------------- Key: HHH-6396 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6396 Project: Hibernate Core Issue Type: Remove Feature Components: annotations Affects Versions: 4.0.0.next Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.1.0 -- 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, 4 months

2
3
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