July 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2268) JDK Bug 5062759 Breaks Hibernate Introspection

by James Olsen (JIRA)

JDK Bug 5062759 Breaks Hibernate Introspection ---------------------------------------------- Key: HHH-2268 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2268 Project: Hibernate3 Type: Patch Components: core Versions: 3.2.0.ga Environment: n/a Reporter: James Olsen Priority: Blocker Attachments: patch.txt Class#getDeclaredMethods() returns inherited methods - see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5062759 This can result in Hibernate failing to determine the correct return type for a method that overrides an inherited method and further constrains the return type. Behaviour is nondeterministic as it depends on the order of the returned array, e.g. public volatile java.lang.Object com.xxx.impl.CPMImpl.getId() // from interface implemented by superclass public volatile com.xxx.api.CPMId com.xxx.impl.CPMImpl.getId() // from superclass implementation public com.xxx.impl.CPMIdImpl com.xxx.impl.CPMImpl.getId() // local The patch checks if the method is 'volatile' and ignores it if it is. -- 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, 9 months

5
14
0 / 0

[Hibernate-JIRA] Created: (EJB-225) EntityManager.find infinite loop related to ANN-381

by John Schneider (JIRA)

EntityManager.find infinite loop related to ANN-381 --------------------------------------------------- Key: EJB-225 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-225 Project: Hibernate Entity Manager Type: Bug Environment: Hibernate Annotations 3.2.0.cr2 Hibernate EntityManager 3.2.0.cr2 Hibernate Core 3.2.0.cr4 Reporter: John Schneider Attachments: Test.zip I've tested the fix for ANN-381 and found that the improvement is not working correctly with the Entity Manager, specifically the find method. When calling the find method on a OneToMany collection mapped by a field in a primary key class, the Entity manager goes into an infinite loop of selecting records. Please note that a workaround is to replace the entity managers find method with a query, such as this: Query query = entityManager.createQuery("select c from Card c where c.id = :id"); query.setParameter("id", id); return (Card) query.getSingleResult(); However, this workaround doesn't work if you have other entities that relate to something like the Card entity, shown below. I'll expand on the example code from ANN-381 to show the problem of infinite looping when trying to load the related collection. @Entity public class Card implements Serializable { @Id private String id; @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy = "primaryKey.card") private Set<CardField> fields; public Card(String id) { this(); this.id = id; } Card() { fields = new HashSet<CardField>(); } public String getId() { return id; } public void setId(String id) { this.id = id; } public void addField(Card card, Key key) { fields.add(new CardField(card, key)); } } @Entity public class CardField implements Serializable { @EmbeddedId private PrimaryKey primaryKey; CardField(Card card, Key key) { this.primaryKey = new PrimaryKey(card, key); } CardField() { } } @Embeddable public class PrimaryKey implements Serializable { @ManyToOne(optional = false) private Card card; @ManyToOne(optional = false) private Key key; public PrimaryKey(Card card, Key key) { this.card = card; this.key = key; } PrimaryKey() {} } @Entity public class Key implements Serializable { @Id private String id; public Key(String id) { this.id = id; } Key() { } } >From what I can tell, this maps fine with the correct Hibernate libs and JBoss EJB Embeddable Alpha 9. However, the Entity Manager must be creating bad query code or something with similar results to having bad queries. I've testing with the following DAO: @Stateless public class CardDAOBean implements CardDAOLocal { @PersistenceContext private EntityManager entityManager; public void createCard(Card card) { entityManager.persist(card); } public Card findCard(String id) { return entityManager.find(Card.class, id); } public void createKey(Key key) { entityManager.persist(key); } } The Test class: public class EJBTest { private Card card; private Key key; public static void main(String[] args) { TestRunner.run(suite()); } public static junit.framework.Test suite() { TestSuite suite = new TestSuite("Test for ANN-381"); suite.addTest(new JUnit4TestAdapter(EJBTest.class)); // setup test so that embedded JBoss is started/stopped once for all // tests here. TestSetup wrapper = new TestSetup(suite) { protected void setUp() { startupEmbeddedJboss(); } protected void tearDown() { shutdownEmbeddedJboss(); } }; return wrapper; } @Before public void setup() { card = new Card("cardId"); key = new Key("keyId"); card.addField(card, key); } @Test public void persist() throws Exception { InitialContext ctx = getInitialContext(); CardDAOLocal CardDAOLocal = (CardDAOLocal) ctx.lookup("CardDAOBean/local"); CardDAOLocal.createKey(key); CardDAOLocal.createCard(card); Card card = CardDAOLocal.findCard(this.card.getId()); assertNotNull(card); } private static void startupEmbeddedJboss() { EJB3StandaloneBootstrap.boot(null); EJB3StandaloneBootstrap.scanClasspath(); } private static void shutdownEmbeddedJboss() { EJB3StandaloneBootstrap.shutdown(); } public static InitialContext getInitialContext() throws Exception { Hashtable properties = getInitialContextProperties(); return new InitialContext(properties); } private static Hashtable getInitialContextProperties() { Hashtable<String, String> props = new Hashtable<String, String>(); props.put("java.naming.factory.initial", "org.jnp.interfaces.LocalOnlyContextFactory"); props.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); return props; } } Here's some relevant debugging output: Row insert: update CardField set card_id=? where card_id=? and key_id=? Row delete: update CardField set card_id=null where card_id=? and card_id=? and key_id=? One-shot delete: update CardField set card_id=null where card_id=? Static select for entity entity.CardField: select cardfield0_.card_id as card2_1_0_, cardfield0_.key_id as key1_1_0_ from CardField cardfield0_ where cardfield0_.card_id=? and cardfield0_.key_id=? Static select for action ACTION_MERGE on entity entity.CardField: select cardfield0_.card_id as card2_1_0_, cardfield0_.key_id as key1_1_0_ from CardField cardfield0_ where cardfield0_.card_id=? and cardfield0_.key_id=? Static select for action ACTION_REFRESH on entity entity.CardField: select cardfield0_.card_id as card2_1_0_, cardfield0_.key_id as key1_1_0_ from CardField cardfield0_ where cardfield0_.card_id=? and cardfield0_.key_id=? Static select for entity entity.Card: select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? Static select for entity entity.Card: select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? Static select for entity entity.Card: select card0_.id as id0_0_ from Card card0_ where card0_.id=? Static select for entity entity.Card: select card0_.id as id0_0_ from Card card0_ where card0_.id=? Static select for entity entity.Card: select card0_.id as id0_0_ from Card card0_ where card0_.id=? Static select for action ACTION_MERGE on entity entity.Card: select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? Static select for action ACTION_REFRESH on entity entity.Card: select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? Static select for entity entity.Key: select key0_.id as id2_0_ from Key key0_ where key0_.id=? Static select for entity entity.Key: select key0_.id as id2_0_ from Key key0_ where key0_.id=? Static select for entity entity.Key: select key0_.id as id2_0_ from Key key0_ where key0_.id=? Static select for entity entity.Key: select key0_.id as id2_0_ from Key key0_ where key0_.id=? Static select for entity entity.Key: select key0_.id as id2_0_ from Key key0_ where key0_.id=? Static select for action ACTION_MERGE on entity entity.Key: select key0_.id as id2_0_ from Key key0_ where key0_.id=? Static select for action ACTION_REFRESH on entity entity.Key: select key0_.id as id2_0_ from Key key0_ where key0_.id=? Static select for one-to-many entity.Card.fields: select fields0_.card_id as card2_1_, fields0_.key_id as key1_1_, fields0_.card_id as card2_1_0_, fields0_.key_id as key1_1_0_ from CardField fields0_ where fields0_.card_id=? When I call the findCard method in my EJB, the entity manager keeps looping through the select process several hundred times, and then dies from a stack overflow. Here's a sample of looping: DEBUG 17-09 21:17:18,328 (Log4JLogger.java:debug:84) -select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? DEBUG 17-09 21:17:18,343 (Log4JLogger.java:debug:84) -about to open ResultSet (open ResultSets: 0, globally: 0) DEBUG 17-09 21:17:18,343 (Log4JLogger.java:debug:84) -loading entity: [entity.Card#cardId] DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -about to open PreparedStatement (open PreparedStatements: 1, globally: 1) DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -about to open ResultSet (open ResultSets: 1, globally: 1) DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -loading entity: [entity.Card#cardId] DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -about to open PreparedStatement (open PreparedStatements: 2, globally: 2) DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -about to open ResultSet (open ResultSets: 2, globally: 2) DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -loading entity: [entity.Card#cardId] DEBUG 17-09 21:17:18,359 (Log4JLogger.java:debug:84) -about to open PreparedStatement (open PreparedStatements: 3, globally: 3) DEBUG 17-09 21:17:18,375 (Log4JLogger.java:debug:84) -select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? DEBUG 17-09 21:17:18,375 (Log4JLogger.java:debug:84) -about to open ResultSet (open ResultSets: 3, globally: 3) DEBUG 17-09 21:17:18,375 (Log4JLogger.java:debug:84) -loading entity: [entity.Card#cardId] DEBUG 17-09 21:17:18,375 (Log4JLogger.java:debug:84) -about to open PreparedStatement (open PreparedStatements: 4, globally: 4) DEBUG 17-09 21:17:18,375 (Log4JLogger.java:debug:84) -select card0_.id as id0_1_, fields1_.card_id as card2_3_, fields1_.key_id as key1_3_, fields1_.card_id as card2_1_0_, fields1_.key_id as key1_1_0_ from Card card0_ left outer join CardField fields1_ on card0_.id=fields1_.card_id where card0_.id=? DEBUG 17-09 21:17:18,375 (Log4JLogger.java:debug:84) -about to open ResultSet (open ResultSets: 4, globally: 4) DEBUG 17-09 21:17:18,375 (Log4JLogger.java:debug:84) -loading entity: [entity.Card#cardId] -- 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, 9 months

8
23
0 / 0

[Hibernate-JIRA] Created: (HHH-5253) TableHiLoGenerator does not increment hi-value any more when lo-range es exhausted

by Martin Gubser (JIRA)

TableHiLoGenerator does not increment hi-value any more when lo-range es exhausted ---------------------------------------------------------------------------------- Key: HHH-5253 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5253 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2, 3.5.1 Environment: Hibernate 3.5.2, DB2 v9.7 Reporter: Martin Gubser Attachments: A.java, HiLoTest.java The {{TableHiLoGenerator}} increments the lo value when it first gets a lo-range but not any more when it grabs further lo-ranges. The first run of the attached program leaves the hi-value=1. Consequently on the second run it uses an id that has already been assigned to. -- 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, 9 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5245) Introduce LobHelper

by Steve Ebersole (JIRA)

Introduce LobHelper ------------------- Key: HHH-5245 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5245 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 As the preferred way to interact with JDBCSupport as currently defined on org.hibernate.Hibernate (and deprecate those) -- 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, 9 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5248) Introduce CompositeType interface (to replace AbstractComponentType interface)

by Steve Ebersole (JIRA)

Introduce CompositeType interface (to replace AbstractComponentType interface) ------------------------------------------------------------------------------ Key: HHH-5248 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5248 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 -- 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, 9 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5200) Prepare to use H2 as the default testing datbase

by Steve Ebersole (JIRA)

Prepare to use H2 as the default testing datbase ------------------------------------------------ Key: HHH-5200 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5200 Project: Hibernate Core Issue Type: Task Components: core, testsuite Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 Evaluate the current couple of errors against H2 to determine cause(s). -- 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, 9 months

1
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5069) Fix annotation documentation wrt setup

by Steve Ebersole (JIRA)

Fix annotation documentation wrt setup -------------------------------------- Key: HHH-5069 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5069 Project: Hibernate Core Issue Type: Bug Components: annotations, documentation Affects Versions: 3.5.0-Final Reporter: Steve Ebersole Fix For: 3.5.x http://in.relation.to/Bloggers/Hibernate350FinalRelease#comment15080 The annotation guide seems to document incorrectly the steps getting started in terms of copying jars from the distribution to the developer project. Specificially it appears to call call for copying: * hibernate-annotations.jar (part of hibernate3.jar) * lib/hibernate-comons-annotations.jar (part of hibernate3.jar) * lib/hibernate-jpa-2.0-api.jar (actually under jpa/, not lib/) -- 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, 9 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5218) Provide a new "pooled value" based optimizer which interprets the database value as the low boundary instead of upper boundary

by Steve Ebersole (JIRA)

Provide a new "pooled value" based optimizer which interprets the database value as the low boundary instead of upper boundary ------------------------------------------------------------------------------------------------------------------------------ Key: HHH-5218 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5218 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.2.6 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.2, 3.6 Splitting up HHH-3608 into its individual tasks. This part deals with the assumption made in PooledOptimizer that the sequence value is the upper boundary of the current range of values. This is an assumption and the other assumption that the value is the lower boundary is just as valid, so provide for both by adding a new optimizer. The new optimizer class will be org.hibernate.id.enhanced.OptimizerFactory.PooledLoOptimizer and its short name will be "pooled-lo". The already existing one will remain the default, but I will add a config option to allow users to specify which to use per setup ('hibernate.id.prefer_pooling_lo_values'). -- 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, 9 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5131) SchemaExport drop fails if constraint names change

by Strong Liu (JIRA)

SchemaExport drop fails if constraint names change -------------------------------------------------- Key: HHH-5131 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5131 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.3.2 Environment: PostgreSQL Reporter: Strong Liu Fix For: 3.3.x, 3.5.x for PostgreSQL dialect, it doesn't use cascade to drop tables, this may causes error when it drops the constraints. for example, there is a table A with a FK which name is "123456" but schemaUpdate uses a different FK name to drop it, then fails, then it tries to drop Table A, fails again :( HB-540 was reported a long ago, and Gavin added a comment "We can't apply this patch since older versions of Postgres don't support the cascade syntax." but I don't think it is still a problem( it was a comment added in 2003), as even the PostgreSQL 7.x support this syntax -- 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, 9 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5032) Setting LockModeType.OPTIMISTIC_FORCE_INCREMENT defaults to only OPTIMISTIC

by Carlos Vara (JIRA)

Setting LockModeType.OPTIMISTIC_FORCE_INCREMENT defaults to only OPTIMISTIC --------------------------------------------------------------------------- Key: HHH-5032 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5032 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.0-CR-2 Environment: Hibernate Core 3.5.0-CR-2, Hibernate Validator 4.1 Snapshot, Spring 3.0.1, JPA2 Reporter: Carlos Vara Using EntityManager.lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT) doesn't change lock type, and version doesn't get updated on transaction commit. The following code: System.out.println("PRE lock mode: " + this.entityManager.getLockMode(an)); this.entityManager.lock(an, LockModeType.OPTIMISTIC_FORCE_INCREMENT); System.out.println("POST lock mode: " + this.entityManager.getLockMode(an)); Outputs: PRE lock mode: OPTIMISTIC POST lock mode: OPTIMISTIC Debugging AbstractLockUpgradeEventListener.upgradeLock, the reason is it doesn't upgrade it because previous lock mode is "READ" (whose level is 5), and OPTIMISTIC_FORCE_INCREMENT has level 4, so it doesn't trigger the update. I'm not sure about Hibernate's LockMode, but I think that OPTIMISTIC_FORCE_INCREMENT is a bit more restrictive than just OPTIMISTIC, so the locking type should be upgraded. -- 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, 9 months

5
20
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 July 2010