[Hibernate-JIRA] Created: (HSEARCH-926) Duplicate InfinispanDirectoryProviders created when multiple sub-classes share the same index directory
by Zach Kurey (JIRA)
Duplicate InfinispanDirectoryProviders created when multiple sub-classes share the same index directory
-------------------------------------------------------------------------------------------------------
Key: HSEARCH-926
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-926
Project: Hibernate Search
Issue Type: Bug
Components: directory provider, infinispan
Affects Versions: 3.4.1.Final
Reporter: Zach Kurey
InfinispanDirectoryProvider doesn't implement hashCode/equals. When multiple subclasses of the same type share the same index directory duplicates are created. The end result from an application perspective leads to duplicate search results, and lots of side effects like:
java.io.FileNotFoundException: Error loading medatada for index file: _b.fnm|M|Location
at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:300)
The errors and duplicates go away after overriding hashCode/equals based on directoryProviderName
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-3887) Envers hbm xml based configuration
by Helmut Pasch (JIRA)
Envers hbm xml based configuration
----------------------------------
Key: HHH-3887
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Affects Versions: 3.5
Environment: Hibernate: All Hibernate Versions including Envers as subproject
Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, ....
Reporter: Helmut Pasch
Currently the tool library Envers can only be configured / mapped to java POJOs by annotations. We would appreciate if this mapping could be done by hbm xml files. Using this approach the POJO won't be bound to Envers annotations. They simply would be left as POJOs instead of transformed to JPA like Entity Beans.
We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see only two options objects may leave the server tier. First by a copy to an annotation less value object, which is consuming performance and resources. Second by coping / using Envers / Hibernate libraries for reference purposes on the client tier.
Both solutions are not very attractive compared to the very well working hbm xml approach Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in client server communication model transformations like coping objects or transforming them to other formats like XML, e.g. like web services does. The easiest way would be to just serialize the Java POJO objects. But never then less the client should only depend (logically) on the server API. It is not intended to rely on a specific server implementation.
--
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
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6768) Hibernate Search archetype resolver generated ${project.version} as org.hibernate:hibernate-search-analyzers version
by Karel Piwko (JIRA)
Hibernate Search archetype resolver generated ${project.version} as org.hibernate:hibernate-search-analyzers version
--------------------------------------------------------------------------------------------------------------------
Key: HHH-6768
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6768
Project: Hibernate Core
Issue Type: Bug
Components: build
Affects Versions: 4.0.0.CR1
Reporter: Karel Piwko
When an archetype is generated, following dependency is managed by dependencyManagement in hibernate-search-parent. However, the version is not resolved to 4.0.0.CR1 but to actual project version, which is likely 1.0-SNAPSHOT (the default)
{code}
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-search-analyzers</artifactId>
</dependency>
{code}
Following error happens:
{code}
[INFO] Building Hibernate Search Quickstart 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.1:generate (default-cli) @ hibernate-search-quickstart >>>
[WARNING] The POM for org.hibernate:hibernate-search-analyzers:jar:1.0-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12.977s
[INFO] Finished at: Tue Oct 25 14:52:46 CEST 2011
[INFO] Final Memory: 6M/116M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project hibernate-search-quickstart: Could not resolve dependencies for project org.jboss.wfk.hibernate.search:hibernate-search-quickstart:jar:1.0-SNAPSHOT: Failure to find org.hibernate:hibernate-search-analyzers:jar:1.0-SNAPSHOT in https://repository.jboss.org/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExce...
{code}
Workaround: Include version by yourself
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months