February 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-669) String2FieldBridgeAdaptor does not implement StringBridge causing DocumentBuilderIndexedEntity to not recognize it as a StringBridge

by Brian Langel (JIRA)

String2FieldBridgeAdaptor does not implement StringBridge causing DocumentBuilderIndexedEntity to not recognize it as a StringBridge ------------------------------------------------------------------------------------------------------------------------------------ Key: HSEARCH-669 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-669 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.3.0.Final Environment: Tested against 3.3.0.Final, database agnostic. Reporter: Brian Langel Attachments: string2fieldbridgeadapterfailure.tar See attached source code (maven project. 'mvn test' will run the test case). String2FieldBridgeAdaptor does not implement StringBridge causing DocumentBuilderIndexedEntity to not recognize it as a StringBridge (line 598 in DocumentBuilderIndexedEntity checks if the found FieldBridge is assignable to StringBridge, which for any adapted StringBridge is false since the String2FieldBridgeAdaptor does not implement StringBridge). >From attached test case: org.hibernate.search.SearchException: FieldBridge class org.hibernate.search.bridge.String2FieldBridgeAdaptordoes not have a objectToString method: field value in DomainObject at org.hibernate.search.engine.DocumentBuilderIndexedEntity.objectToString(DocumentBuilderIndexedEntity.java:601) at org.hibernate.search.query.dsl.impl.ConnectedMultiFieldsTermQueryBuilder.buildSearchTerm(ConnectedMultiFieldsTermQueryBuilder.java:133) -- 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

15 years, 1 month

3
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-683) NullPointerException while using DocumentExtract on entities using @ProvidedId

by Sanne Grinovero (JIRA)

NullPointerException while using DocumentExtract on entities using @ProvidedId ------------------------------------------------------------------------------ Key: HSEARCH-683 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-683 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.3.0.Final Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.4.0 DocumentExtractor invokes org.hibernate.search.engine.DocumentBuilderIndexedEntity.getIdentifierName(), but this method is implemented as {code}return idGetter.getName();{code} while idGetter is null when the id is provided. -- 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

15 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-672) Incorrect chapter sections on query's module (Limiting the time of a query)

by Emmanuel Bernard (JIRA)

Incorrect chapter sections on query's module (Limiting the time of a query) --------------------------------------------------------------------------- Key: HSEARCH-672 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-672 Project: Hibernate Search Issue Type: Bug Components: documentation Affects Versions: 3.3.0.Final Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.4.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

15 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-652) Cache NumericField usage in Delete operation for single entity-per-index case

by Sanne Grinovero (JIRA)

Cache NumericField usage in Delete operation for single entity-per-index case ----------------------------------------------------------------------------- Key: HSEARCH-652 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-652 Project: Hibernate Search Issue Type: Improvement Components: engine Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 3.4.0 org.hibernate.search.backend.impl.lucene.works.DeleteExtWorkDelegate has some extra knowledge on the model which is not being used -- 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

15 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-658) Create test to check dirtyness of mutable properties

by Sanne Grinovero (JIRA)

Create test to check dirtyness of mutable properties ---------------------------------------------------- Key: HSEARCH-658 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-658 Project: Hibernate Search Issue Type: Task Components: engine Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 3.4.0 Follow up of HSEARCH-361, as Emmanuel suggests on mailing list we should also have a test to cover for changes on mutable properties. -- 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

15 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-651) Improve error reporting on null values in querybuilder DSL

by Sanne Grinovero (JIRA)

Improve error reporting on null values in querybuilder DSL ---------------------------------------------------------- Key: HSEARCH-651 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-651 Project: Hibernate Search Issue Type: Improvement Components: query Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 3.4.0 >From forum thread: https://forum.hibernate.org/viewtopic.php?f=9&t=1008832 Something wrong, but there's a typo in first error message and the NPE definitely doesn't help understand the issue. -- 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

15 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-650) Regression in 3.3.0: Using hibernate.use_identifier_rollback property causes exceptions on deletes

by Kyrill Alyoshin (JIRA)

Regression in 3.3.0: Using hibernate.use_identifier_rollback property causes exceptions on deletes -------------------------------------------------------------------------------------------------- Key: HSEARCH-650 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-650 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.3.0.Final Environment: Hibernate 3.6.0, Hibernate Search 3.3.0 Reporter: Kyrill Alyoshin Basically, when Hibernate is configured with 'hibernate.use_identifier_rollback' (that is to set primary keys of the deleted entities to null), here is what happens: {code} 2010-12-17 18:52:51,187 TRACE [Hibernate Search: Directory writer-1|] org.hibernate.search.backend.impl.lucene.works.DeleteExtWorkDelegate => Removing class xxx.Vendor#null by id using an IndexWriter. 2010-12-17 18:52:51,187 ERROR [Hibernate Search: Directory writer-1|] org.hibernate.search.backend.impl.lucene.PerDPQueueProcessor => Unexpected error in Lucene Backend: java.lang.NullPointerException at org.apache.lucene.index.TermBuffer.set(TermBuffer.java:95) at org.apache.lucene.index.SegmentTermEnum.scanTo(SegmentTermEnum.java:160) at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:232) at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:179) at org.apache.lucene.index.SegmentTermDocs.seek(SegmentTermDocs.java:57) at org.apache.lucene.index.DocumentsWriter.applyDeletes(DocumentsWriter.java:1046) at org.apache.lucene.index.DocumentsWriter.applyDeletes(DocumentsWriter.java:1004) at org.apache.lucene.index.IndexWriter.applyDeletes(IndexWriter.java:4566) at org.apache.lucene.index.IndexWriter.doFlushInternal(IndexWriter.java:3756) at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3595) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3585) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1717) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1680) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1644) at org.hibernate.search.backend.Workspace.closeIndexWriter(Workspace.java:211) at org.hibernate.search.backend.impl.lucene.PerDPQueueProcessor.run(PerDPQueueProcessor.java:113) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) 2010-12-17 18:52:51,187 ERROR [Hibernate Search: Directory writer-1|] org.hibernate.search.exception.impl.LogErrorHandler => Exception occurred java.lang.NullPointerException Primary Failure: Entity xxx.Vendor Id null Work Type org.hibernate.search.backend.DeleteLuceneWork java.lang.NullPointerException at org.apache.lucene.index.TermBuffer.set(TermBuffer.java:95) at org.apache.lucene.index.SegmentTermEnum.scanTo(SegmentTermEnum.java:160) at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:232) at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:179) at org.apache.lucene.index.SegmentTermDocs.seek(SegmentTermDocs.java:57) at org.apache.lucene.index.DocumentsWriter.applyDeletes(DocumentsWriter.java:1046) at org.apache.lucene.index.DocumentsWriter.applyDeletes(DocumentsWriter.java:1004) at org.apache.lucene.index.IndexWriter.applyDeletes(IndexWriter.java:4566) at org.apache.lucene.index.IndexWriter.doFlushInternal(IndexWriter.java:3756) at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3595) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3585) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1717) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1680) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1644) at org.hibernate.search.backend.Workspace.closeIndexWriter(Workspace.java:211) at org.hibernate.search.backend.impl.lucene.PerDPQueueProcessor.run(PerDPQueueProcessor.java:113) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) 2010-12-17 18:52:51,187 WARN [Hibernate Search: Directory writer-1|] org.hibernate.search.backend.Workspace => going to force release of the IndexWriter lock {code} This has not happened in 3.2.1 and Hibernate 3.5.4. I believe this is a serious regression issue. -- 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

15 years, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (HV-434) ValidatorImpl#shouldFailFast() and ValidationContext#shouldFailFast() seem redundant

by Gunnar Morling (JIRA)

ValidatorImpl#shouldFailFast() and ValidationContext#shouldFailFast() seem redundant ------------------------------------------------------------------------------------ Key: HV-434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-434 Project: Hibernate Validator Issue Type: Improvement Components: engine Reporter: Gunnar Morling Priority: Minor Fix For: 4.2.0.CR1 This is a follow-up issue to HV-381. The two methods ValidatorImpl#shouldFailFast() and ValidationContext#shouldFailFast() seem redundant, one should be removed IMO (see https://github.com/hibernate/hibernate-validator/pull/25/files#r1349). In case we actually need both methods this issue can be closed without further actions. -- 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

15 years, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (HV-429) validateValue and validateProperty using wrong default group sequence

by Kevin Pollet (JIRA)

validateValue and validateProperty using wrong default group sequence --------------------------------------------------------------------- Key: HV-429 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-429 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.x Reporter: Kevin Pollet When using the _Validator#validateValue_ or _Validator#validateProperty_ methods the default group sequence used is wrong. Instead of using respectively the default group sequence of the hosting class or the hosting bean the default group sequence of the root bean or root class is used. -- 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

15 years, 1 month

2
6
0 / 0

[Hibernate-JIRA] Created: (HV-421) Reconsider behavior of parameter validation for inheritance hierarchies

by Gunnar Morling (JIRA)

Reconsider behavior of parameter validation for inheritance hierarchies ----------------------------------------------------------------------- Key: HV-421 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-421 Project: Hibernate Validator Issue Type: Bug Components: engine Reporter: Gunnar Morling Fix For: 4.2.0.Beta2 Let A extend B and A#foo() override B#foo(). When validating an invocation of A#foo() the current implementation will evaluate all parameter constraints defined at A#foo() *and* B#foo(). That way the foo()'s preconditions defined in B are strengthened by A. According to the ["Programming by contract"|http://en.wikipedia.org/wiki/Programming_by_contract] article on WP this is not allowed, subtypes may only weaken preconditions defined by supertypes. The common implementation pattern for this is to combine the preconditions within a hierarchy by a logical OR, meaning the weakest precondition in the hierarchy applies. Note that postconditions (return value constraints) may be strengthened (but not weakened) by subtypes. Therefore the current implementation (AND combination) should be correct here. -- 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

15 years, 1 month

2
16
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 February 2011