[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
[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
[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
[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
[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
[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