April 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5150) Update settings section to reflect merge from Annotations and Core documentation

by Emmanuel Bernard (JIRA)

Update settings section to reflect merge from Annotations and Core documentation -------------------------------------------------------------------------------- Key: HHH-5150 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5150 Project: Hibernate Core Issue Type: Sub-task Reporter: Emmanuel Bernard -- 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, 2 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5094) PersistenceUtilHelper cannot access non-public fields/methods (it should be able to)

by Philip Clay (JIRA)

PersistenceUtilHelper cannot access non-public fields/methods (it should be able to) ------------------------------------------------------------------------------------ Key: HHH-5094 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5094 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0-Final Environment: 3.5.0-Final. Any environment Reporter: Philip Clay Attachments: hibernate-entitymanager-bugreproduction.tgz PersistenceUtilHelper is only able to access public fields and public methods. As it is written, it cannot access non-public members. Internally, it incorrectly uses Class.getField(...) and Class.getMethod(...). It should use Class.getDeclaredField(...) and Class.getDeclaredMethod(...), so that it can see non-public members. I believe the use of getField and getMethod is not indented, because setAccessibility is the next call after that. Here is the code... {code} private static Object get(Object proxy, String property) { final Class<?> clazz = proxy.getClass(); try { try { final Field field = clazz.getField( property ); // only retrieves public fields!!! setAccessibility( field ); // if you really only wanted public fields, this call is unnecessary! return field.get( proxy ); } catch ( NoSuchFieldException e ) { final Method method = getMethod( clazz, property ); if (method != null) { setAccessibility( method ); // if you really only wanted public methods, this call is unnecessary! return method.invoke( proxy ); } ... } private static Method getMethod(Class<?> clazz, String methodName) { try { char string[] = methodName.toCharArray(); string[0] = Character.toUpperCase( string[0] ); methodName = new String( string ); try { return clazz.getMethod( "get" + methodName ); // only retrieves public methods!!! } catch ( NoSuchMethodException e ) { return clazz.getMethod( "is" + methodName ); // only retrieves public methods!!! } ... } private static void setAccessibility(Member member) { if ( !Modifier.isPublic( member.getModifiers() ) ) { //Sun's ease of use, sigh... ( ( AccessibleObject ) member ).setAccessible( true ); // This is dead code! The input member will always be public } } {code} Notice the call to setAccessibility. The call to setAccessibility shows that one assumes that the field retrieved from getField() (or method from getMethod()) could be non-public, which in fact it can't. All fields returned from getField will always be public (same for getMethod()). So, essentially the code inside the if statement in setAccessibility is dead code. I have attached a tarball containing a failing testcase that shows the incorrect behavior. Explode the tarball and run "mvn test" to reproduce the incorrect behavior. Also, within the tarball, I have included an svn diff for a proposed patch. See the README.txt file within the tarball for more info. I first noticed this problem when using hibernate validator to validate some protected members, but I narrowed it down to a problem in PersistenceUtilHelper. -- 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, 2 months

5
9
0 / 0

[Hibernate-JIRA] Created: (HHH-4945) Replace all usages of EJB3TestCase with org.hibernate.ejb.test.TestCase

by Hardy Ferentschik (JIRA)

Replace all usages of EJB3TestCase with org.hibernate.ejb.test.TestCase ----------------------------------------------------------------------- Key: HHH-4945 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4945 Project: Hibernate Core Issue Type: Improvement Components: entity-manager Affects Versions: 3.5.0-CR-1 Reporter: Hardy Ferentschik Fix For: 3.5.x The setup in EJB3TestCase is really strange and we really want to have as many test as possible to derive from your main test base class. -- 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, 2 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3765) Fill the "end revision" column with appropriate data in add/mod/del/collection work units

by Adam Warski (JIRA)

Fill the "end revision" column with appropriate data in add/mod/del/collection work units ----------------------------------------------------------------------------------------- Key: HHH-3765 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3765 Project: Hibernate Core Issue Type: Sub-task Components: envers Reporter: Adam Warski Assignee: Adam Warski In case of modifications, not only the "end revision" column should be set on new data, but also modified on existing data. -- 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, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3764) Add the "end-revision" column when generating metadata

by Adam Warski (JIRA)

Add the "end-revision" column when generating metadata ------------------------------------------------------ Key: HHH-3764 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3764 Project: Hibernate Core Issue Type: Sub-task Components: envers Reporter: Adam Warski Assignee: Adam Warski The column would only be added if the necessary setting is set to true. The column will have the same type as the revision number, but will be nullable. -- 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, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4568) Sybase - Test "BatchTest" fails due to "unexpected row count from update"

by Strong Liu (JIRA)

Sybase - Test "BatchTest" fails due to "unexpected row count from update" ------------------------------------------------------------------------- Key: HHH-4568 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4568 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Beta-2, 3.5.0.Beta-1, 3.3.2, 3.2.4.sp1 Environment: Sybase Reporter: Strong Liu Assignee: Strong Liu Fix For: 3.2.x, 3.3.x, 3.5, 3.3.0.GA, 3.2.4.sp1 The test "BatchTest" fails due to "org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1". The database server seems configured properly, as the "BatchUpdates" sample from jConnect 6 works correctly. The problem specifically occurs with a table that has a numeric column with precision (e.g. numeric(10,4)) Sybase does not thrown any SQLException when you try and persist a numeric value whose scale exceeds that defined on the column. Instead, it returns an updateCount of zero -- 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, 2 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-3579) Support for PostgreSQL UUID data type

by Olivier Van Acker (JIRA)

Support for PostgreSQL UUID data type ------------------------------------- Key: HHH-3579 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3579 Project: Hibernate Core Issue Type: New Feature Components: core Affects Versions: 3.3.1 Reporter: Olivier Van Acker PostgreSQL has since version 8.3 UUID as data type nativly supported in the database. The only way to get this to work in Hibernate is to add <column name="id" sql-type="uuid"/> to your mappings file (or @columnDefinition via annotations) and create your own custom usertype (e.g. public class UUIDUserType implements UserType, Serializable {..} ) and map this to java.util.UUID worth mentioning is that java.util.UUID is only introduced in java 1.5 so there might be a backwards compatibility problem -- 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, 2 months

5
22
0 / 0

[Hibernate-JIRA] Created: (HHH-2277) bidirectional <key-many-to-one> both lazy=false fetch=join lead to infinite loop

by Emmanuel Bernard (JIRA)

bidirectional <key-many-to-one> both lazy=false fetch=join lead to infinite loop -------------------------------------------------------------------------------- Key: HHH-2277 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2277 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Reporter: Emmanuel Bernard -- 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, 2 months

2
14
0 / 0

[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

14 years, 2 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

14 years, 2 months

8
23
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2010