April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7101) NPE when trying to create EntityManagerFactory

by Michael Nascimento Santos (JIRA)

NPE when trying to create EntityManagerFactory ---------------------------------------------- Key: HHH-7101 URL: https://hibernate.onjira.com/browse/HHH-7101 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.0 Environment: hibernate-jpa-2.0-api:1.0.1-Final; hibernate-core:4.1.0.Final; hibernate-entitymanager:4.1.0.Final Reporter: Michael Nascimento Santos Attachments: npe4cacheable.zip A NPE is thrown for a simple pure JPA entity annotated with @Cacheable as follows: @Entity @Cacheable public class SampleEntity { @Id @GeneratedValue(strategy=GenerationType.AUTO) private Long id; } When Persistence.createEntityManagerFactory(String) is called and such entity is part of the persistence unit, this produces: java.lang.reflect.InvocationTargetException 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 org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NullPointerException at org.hibernate.annotations.CacheConcurrencyStrategy.fromAccessType(CacheConcurrencyStrategy.java:52) at org.hibernate.cfg.AnnotationBinder.determineCacheConcurrencyStrategy(AnnotationBinder.java:1044) at org.hibernate.cfg.AnnotationBinder.buildCacheMock(AnnotationBinder.java:1011) at org.hibernate.cfg.AnnotationBinder.determineCacheSettings(AnnotationBinder.java:968) at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:577) at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3431) at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3385) at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1337) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1727) at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:88) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:889) at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:56) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:63) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:47) at org.hibernate.test.npe4cacheable.SampleEntity.main(SampleEntity.java:18) ... 6 more Hibernate should either choose some sensible default strategy or produce a clear message indicating the need to set one manually. Attached is a Maven-powered sample with Derby that can be executed with exec:java . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-7256) Infinispan second level cache should react to minimal puts in putFromLoad impl

by Galder Zamarreno (JIRA)

Infinispan second level cache should react to minimal puts in putFromLoad impl ------------------------------------------------------------------------------ Key: HHH-7256 URL: https://hibernate.onjira.com/browse/HHH-7256 Project: Hibernate ORM Issue Type: Improvement Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno When entities are loaded multiple times, it could happen that two consecutive Cache.putForExternalRead() operations are called with the second not affecting the cache if a an entry is already present. However, from a cache put statistics will increase, resulting potentially in a huge number when in reality, the number of actual cache updates has been pretty small. The minimalPuts parameter is there to avoid this, implying that maybe a check if the key is present should be added since PFER does not return a boolean or similar. Although adding that check looks something obvious, it's something that we're probably reluctant to do, because since caches are configured with storeAsBinary=true, it could lead to unmarshalling, slowing things down. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5160) Error on binding values prepared statment in many-to-any relation

by wof (JIRA)

Error on binding values prepared statment in many-to-any relation ----------------------------------------------------------------- Key: HHH-5160 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5160 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.3.2 Environment: Tested on Version 3.3.2 and 3.5.1 on Oracle, PostgreSQL and MySQL Reporter: wof A Collection of Entities is defined as a ManyToAny relation, e.g. @ManyToAny(metaColumn=@Column(name="C_OBJECT_TYPE")) @AnyMetaDef(idType="string", metaType="string", metaValues={ @MetaValue(targetEntity=Entity1.class, value="Entity1"), @MetaValue(targetEntity=Entity2.class, value="Entity2") }) @JoinTable(name="T_OBJECTS", joinColumns=@JoinColumn(name="C_OWNER_ID"), inverseJoinColumns=@JoinColumn(name="C_OBJECT_ID") ) private Set<EntityBase> objects = new HashSet<EntityBase>(); Adding to this set works without problems. Removing all elements from the set (i.e. setting the set to null or zero-sized), too. However, when one or more elements are removed from the set with at least one element remaining, an exception is thrown: org.hibernate.exception.GenericJDBCException: could not delete collection rows with the cause being java.sql.SQLException: Parameter index out of range (3 > number of parameters, which is 2). I have narrowed this problem to this: The mapping table consists of 3 columns, C_OWNER_ID, C_OBJECT_TYPE and C_OBJECT_ID. The generated SQL-statement to delete the rows is as folling: DELETE FROM t_objects WHERE c_owner_id=? AND c_object_id=? However, Hibernate (in org.hibernate.typ.AnyType) tries to bind the actual value for c_object_id with index 3 which causes the exception. I guess Hibernate expects c_object_type to be present in the statement. As workaround we changed nullSafeSet in AnyType to: public void nullSafeSet(PreparedStatement st, Object value, int index, boolean[] settable, SessionImplementor session) throws HibernateException, SQLException { Serializable id; String entityName; if (value==null) { id=null; entityName=null; } else { entityName = session.bestGuessEntityName(value); id = ForeignKeys.getEntityIdentifierIfNotUnsaved(entityName, value, session); } // metaType is assumed to be single-column type // <ORIGINAL CODE> /* if ( settable==null || settable[0] ) { metaType.nullSafeSet(st, entityName, index, session); } if (settable==null) { identifierType.nullSafeSet(st, id, index+1, session); } else { boolean[] idsettable = new boolean[ settable.length-1 ]; System.arraycopy(settable, 1, idsettable, 0, idsettable.length); identifierType.nullSafeSet(st, id, index+1, idsettable, session); } */ // </ORIGINAL CODE> // <PATCHED CODE> if ( settable==null || settable[0] ) { metaType.nullSafeSet(st, entityName, index, session); boolean[] idsettable = new boolean[ settable.length-1 ]; System.arraycopy(settable, 1, idsettable, 0, idsettable.length); identifierType.nullSafeSet(st, id, index+1, idsettable, session); } else if (settable==null) { identifierType.nullSafeSet(st, id, index+1, session); } else { boolean[] idsettable = new boolean[ settable.length-1 ]; System.arraycopy(settable, 1, idsettable, 0, idsettable.length); identifierType.nullSafeSet(st, id, index, idsettable, session); } // </PATCHED CODE> } best regards wof -- 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, 11 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7254) Using Eclipse's JarResrcLoader, an exception occurs: java.lang.StringIndexOutOfBoundsException: String index out of range: -1

by Thomas Siegbert (JIRA)

Using Eclipse's JarResrcLoader, an exception occurs: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 ----------------------------------------------------------------------------------------------------------------------------- Key: HHH-7254 URL: https://hibernate.onjira.com/browse/HHH-7254 Project: Hibernate ORM Issue Type: Bug Components: entity-manager Affects Versions: 4.1.1, 3.6.10 Environment: Hibernate Core 3.6.10, Windows 7 Enterprise, Java SE 1.6.31, DB: Oracle 11.2.0.2, IDE: Eclipse Indigo Reporter: Thomas Siegbert Attachments: export_jar_in_jar.jar, export_libs_outside.rar, JarVisitorFactoryTest.java, log.txt We have a project with a lot of jars. For delivering, we want to pack all jars and the binary code in one executable jar. To build this executable jar, we use the export-functionality from Eclipse. In the wizard in Eclipse, we use the following option for "Library handling": "Package required libraries into generated JAR". If I call this generated executable jar, I will get the following exception: {quote} Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58) Caused by: javax.persistence.PersistenceException: Unable to configure EntityManagerFactory at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:378) at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:56) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:63) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:47) at my.project.Main.main(Main.java:20) ... 5 more Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(Unknown Source) at org.hibernate.ejb.packaging.JarVisitorFactory.getJarURLFromURLEntry(JarVisitorFactory.java:55) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java: 344) ... 9 more {quote} If I do not pack all jars in one jar (instead, I use a sub-folder outside the jar containing all libs), the program works fine. Probably, I have already identified the issue: In the method "_org.hibernate.ejb.packaging.JarVisitorFactory.getJarURLFromURLEntry_" there is the following code line: {quote} file = file.substring( 0, file.length() - entry.length() ); {quote} This works fine, if _file.length()_ is equal or greater than _entry.length()_. In my case ("Jars-in-Jar") the variables in this method got the following content: {quote} file := META-INF/persistence.xml entry := /META-INF/persistence.xml url.toString := rsrc:META-INF/persistence.xml {quote} Thus, _file.length()_ < _entry.length()_ and the exception will be raised. In our project, we fixed it as follows: {quote} file = file.substring( 0, *Math.max( 0, file.length() - entry.length() )* ); {quote} But this is only a suggestion and we cannot foresee any side effects (especially, we do not use an application server). I attached the following files: * JarVisitorFactoryTest.java -> Unit-Tests (which fails using 3.6.10) * export_jar_in_jar.jar -> For reproduction (exception will raised). It is a small project. * export_libs_outside.rar -> Please unpack. This version works fine, because the libs are not within the jar. * log.txt -> stacktrace of the exception. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
4
0 / 0

[Hibernate-JIRA] Created: (OGM-154) Speedup testsuite: EHCache and Infinispan tests are annoyingly slow in their setup phase

by Sanne Grinovero (JIRA)

Speedup testsuite: EHCache and Infinispan tests are annoyingly slow in their setup phase ---------------------------------------------------------------------------------------- Key: OGM-154 URL: https://hibernate.onjira.com/browse/OGM-154 Project: Hibernate OGM Issue Type: Improvement Components: build Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0-next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1098) Update to Apache Lucene 3.6

by Sanne Grinovero (JIRA)

Update to Apache Lucene 3.6 --------------------------- Key: HSEARCH-1098 URL: https://hibernate.onjira.com/browse/HSEARCH-1098 Project: Hibernate Search Issue Type: Improvement Components: engine Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7074) The annotation of @DynamicUpdate has no effect

by zhuzhangsuo (JIRA)

The annotation of @DynamicUpdate has no effect ---------------------------------------------- Key: HHH-7074 URL: https://hibernate.onjira.com/browse/HHH-7074 Project: Hibernate ORM Issue Type: Bug Components: annotations Affects Versions: 4.1.0 Environment: hibernate 4.1.0 mysql 5.1 Reporter: zhuzhangsuo The annotation org.hibernate.annotations.Entity has deprecated ,and it suggest to use @DynamicUpdate to instead of the property dynamicUpdate ,but it has no effect when I modify the value of name The sql of @org.hibernate.annotations.Entity(dynamicUpdate=true): update t_user set user_name=? where user_id=? The sql of @DynamicUpdate: update t_user set user_age=?, user_name=? where user_id=? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-917) DSL API doesn't build the correct Lucene query

by Guillaume Smet (JIRA)

DSL API doesn't build the correct Lucene query ---------------------------------------------- Key: HSEARCH-917 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.4.1.Final Reporter: Guillaume Smet Priority: Critical Hi, A bit of context: We are early adopters of Hibernate Search and we have very few problems with it (except the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far). When the DSL API was introduced, I tried it and I found the problem I describe below. I decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround. The fact is that: * we use Hibernate Search in every application we have, now; * the DSL API is really nice and, as we introduced QueryDSL in our application, we now use a lot of DSL like API and I would like to be able to use Hibernate Search API too; * I thought it was a deliberate choice but, recently I found an example so weird, I can't think it's the wanted behaviour. So this problem isn't new and it exists since the first version of the DSL API. Now, the description of the problem: * we use the following analyzer to index a field in our entity: {code} @AnalyzerDef(name = HibernateSearchAnalyzer.TEXT, tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class), filters = { @TokenFilterDef(factory = ASCIIFoldingFilterFactory.class), @TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = { @org.hibernate.search.annotations.Parameter(name = "generateWordParts", value = "1"), @org.hibernate.search.annotations.Parameter(name = "generateNumberParts", value = "1"), @org.hibernate.search.annotations.Parameter(name = "catenateWords", value = "0"), @org.hibernate.search.annotations.Parameter(name = "catenateNumbers", value = "0"), @org.hibernate.search.annotations.Parameter(name = "catenateAll", value = "0"), @org.hibernate.search.annotations.Parameter(name = "splitOnCaseChange", value = "0"), @org.hibernate.search.annotations.Parameter(name = "splitOnNumerics", value = "0"), @org.hibernate.search.annotations.Parameter(name = "preserveOriginal", value = "1") } ), @TokenFilterDef(factory = LowerCaseFilterFactory.class) } ), {code} * the content of the field is something like XXXX-AAAA-HAGYU-19910 * if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the QueryParser, you have a few results: namely the results which have all the different parts (XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering my analyzer. * if you search using the DSL API, you have ALL the results containing at least ONE token so A LOT of results in our case. My expectation is that the DSL API should work as the Lucene parser works and it should return the same results. The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the analyzer to get all the terms and from that we build a OR query. So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR "AAAA" OR "HAGYU" OR "19910". I really think it's a mistake and that we should use the *QueryParser API to build the Lucene Query and have the correct behaviour. If needed, I can provide any further information and/or a test case. I just want to be sure you consider it a bug before working further on this. Otherwise I'll stick to using the *QueryParser API. Thanks for your feedback. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
15
0 / 0

[Hibernate-JIRA] Created: (OGM-155) change to use org.javassist:javassist:3.15.0-GA

by Strong Liu (JIRA)

change to use org.javassist:javassist:3.15.0-GA ----------------------------------------------- Key: OGM-155 URL: https://hibernate.onjira.com/browse/OGM-155 Project: Hibernate OGM Issue Type: Task Components: build Reporter: Strong Liu ORM is using this version of javassist, it would better that OGM uses the same version for testing -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5043) Incorrect handling of hibernate.default_schema in SchemaUpdate

by Vladimir Klyushnikov (JIRA)

Incorrect handling of hibernate.default_schema in SchemaUpdate -------------------------------------------------------------- Key: HHH-5043 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5043 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-CR-2 Environment: Hibernate Core 3.5.0-CR-2, Oracle 10.2 Reporter: Vladimir Klyushnikov Attachments: cfg.patch While HHH-735 fixes default_schema handling in general, it still has a bug. When SchemaUpdate reads foreign keys metainfo is doesn't honor default_schema and default_catalog settings. The fix is simple and patch is attached. -- 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, 11 months

3
7
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 April 2012