February 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3739) Problem using BTMTransactionManagerLookup with Tomcat

by Helder Sousa (JIRA)

Problem using BTMTransactionManagerLookup with Tomcat ----------------------------------------------------- Key: HHH-3739 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3739 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3.1 GA Reporter: Helder Sousa Attachments: BTMTransactionManagerLookup.patch Hi. When using Bitronix Transaction Manager with tomcat there is a problem resolving the TransactionManager by JNDI. Please take a look to this thread: http://www.nabble.com/Hibernate-JTATransactionFactory-and-BTMTransactionM... In 5th post, Ludovic wrote: "The UserTransaction name is java:comp/UserTransaction and when a JNDI lookup happens in Tomcat, the Tomcat provider takes precedence because Tomcat registered a java: namespace handler." So, when using BTM in Tomcat, the BTM users should configure in BTM Configuration a JNDI name that does not start with java:comp and the BTMTransactionManagerLookup class should read this configuration: Here is the change to the BTMTransactionManagerLookup class (I attached the patch): public String getUserTransactionName() { try { Class transactionManagerServiceClass = Class.forName("bitronix.tm.TransactionManagerServices"); Method getConfigurationMethod = transactionManagerServiceClass.getMethod("getConfiguration", null); Object configurationInstance = getConfigurationMethod.invoke(null, null); Class bitronixConfigurationClass = configurationInstance.getClass(); Method getJndiUserTransactionNameMethod = bitronixConfigurationClass .getMethod("getJndiUserTransactionName", null); String configuredJndiUserTransactionName = (String) getJndiUserTransactionNameMethod.invoke( configurationInstance, null); if (configuredJndiUserTransactionName != null && configuredJndiUserTransactionName.trim().length() >= 0) { return configuredJndiUserTransactionName; } return "java:comp/UserTransaction"; } catch (Exception e) { throw new HibernateException("Could not obtain BTM UserTransactionName", e); } } Can you apply the patch? Best regards, Helder Sousa -- 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

16 years, 1 month

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4937) Exception while saving when using a set and an association to the same target class

by Jean-Noel Rivasseau (JIRA)

Exception while saving when using a set and an association to the same target class ----------------------------------------------------------------------------------- Key: HHH-4937 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4937 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Linux Sun JDK 1.6 Reporter: Jean-Noel Rivasseau Priority: Critical Attachments: list-association.zip The attached files reproduce the problem. As you will see in the source files there are different variations: if you turn off the cascade on the association, it will work. The exception is: Exception in thread "main" org.hibernate.PropertyValueException: not-null property references a null or transient value: Computer._computersBackref -- 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

16 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4934) Improve logging in MetadataContext and AttributeFactory

by Steve Ebersole (JIRA)

Improve logging in MetadataContext and AttributeFactory ------------------------------------------------------- Key: HHH-4934 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4934 Project: Hibernate Core Issue Type: Improvement Components: entity-manager, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.0-CR-2 At a bare minimum we should be logging the class (entity/super/embeddable) we are currently processing and the attribute we are currently processing. This would also be a good spot for some MDC/NDC usage (NDC because of the recursion in processing embeddables). -- 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

16 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4935) one to one(join column in right place) causes HQL eager fetch failure

by Dean Hiller (JIRA)

one to one(join column in right place) causes HQL eager fetch failure --------------------------------------------------------------------- Key: HHH-4935 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4935 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.2 Environment: linux, windows, junit test with hibernate 3.3.4, 3.4 for annotations/entityManager Reporter: Dean Hiller See the end of this post... The test case and all code can be found in here....(just modified the Cat->Kitten example till it broke).... https://forum.hibernate.org/viewtopic.php?f=1&t=1002721&p=2425506#p2425506 basic summary though is if you have SELECT s FROM Cat s inner join fetch s.kitten and you redefine Cat->Kitten to be OneToOne, it works great if JoinColumn is on kitten, but if you move JoinColumn to Cat, it results in a 1+N select where the first sql got all the data needed by hibernate to fill in the Cats and their kitten. We have a 100 page result set that is doing 1+N selects here. ie. if you leave the join column on kitten, the following sql is 1+N then.... SELECT k FROM Kitten k inner join fetch k.cat; (ie. a more likely case since there may be Cats without kitten, but a kitten always have a cat...that is the situation we have in our object model). so onetoone eager fetch joins only work on half the cases out there from what I can tell and you get lucky if your join column is on the right object. -- 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

16 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4583) Wrong SQL constructed when CriteriaQuery.where(...) gets output from CriteriaBuilder.and() with zero args.

by Jaroslaw Lewandowski (JIRA)

Wrong SQL constructed when CriteriaQuery.where(...) gets output from CriteriaBuilder.and() with zero args. ---------------------------------------------------------------------------------------------------------- Key: HHH-4583 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4583 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.5.0-Beta-2 Reporter: Jaroslaw Lewandowski Attachments: Client.java, CriteriaApiTest.java, Name.java As spec says CriteriaBuilder.and(..) returns TRUE for a conjunction of zero predicates. Unfortunately Hibernate throws IllegalArgumentException with cause set to SQL syntax exception: java.lang.IllegalArgumentException: org.hibernate.hql.ast.QuerySyntaxException: unexpected token: null near line 1, column 65 [select generatedAlias0 from foo.Client as generatedAlias0 where ] at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:791) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:148) at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:104) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:158) at foo.CriteriaApiTest.noPredicatesInAnd(CriteriaApiTest.java:43) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41) at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:220) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.hibernate.hql.ast.QuerySyntaxException: unexpected token: null near line 1, column 65 [select generatedAlias0 from foo.Client as generatedAlias0 where ] at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54) at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47) at org.hibernate.hql.ast.ErrorCounter.throwQueryException(ErrorCounter.java:82) at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:284) at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:182) at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80) at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94) at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156) at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135) at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1586) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:133) ... 27 more -- 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

16 years, 1 month

2
9
0 / 0

[Hibernate-JIRA] Commented: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Strong Liu (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496?page=c... ] Strong Liu commented on HHH-1496: --------------------------------- Juca, If this patch does not cause any new failures in our test suite (of course, i mean all of test, not only testsuite sub-module), so I'd suggest you would just commit it to *trunk* > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Juraci Paixao Krohling > Fix For: 3.5.x > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- 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

16 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4060) Dates being converted to Timestamps confuse CollectionUpdateAction/PersistentSet

by Phillip Henry (JIRA)

Dates being converted to Timestamps confuse CollectionUpdateAction/PersistentSet -------------------------------------------------------------------------------- Key: HHH-4060 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4060 Project: Hibernate Core Issue Type: Bug Components: core Environment: Hibernate Trunk, all databases Reporter: Phillip Henry Attachments: timestamp_date_bug.zip If an object that has a Set of java.util.Dates is persisted then retrieved, these element become java.sql.Timestamps. This is fine but PersistentSet then treats Sets of Dates and Timetstamps inconsistently. Eg, if the collection is cleared, this results in CollectionUpdateAction thinking the elements need to be deleted from the DB (see how PersistentSet.getDeletes uses Set.contains() when comparing Dates and Timestamps - leading to a call to Timestamp.equals which Date fails). But if the java.util.Date elements (the same that we started with) are then re-added, CollectionUpdateAction thinks that they are the same as the ones the Set once contained (see how PersistentSet.needsInserting compares the re-added elements with its snapshot - leading to a call to Date.equals which Timestamp passes) and therefore does not think it needs to persist them. The result is that no date elements at all are left in the DB by the time the transaction commits. I've attached a test that demonstrates the 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

16 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4932) Upgrade EM to use the latest metamodel generator (CR-1)

by Hardy Ferentschik (JIRA)

Upgrade EM to use the latest metamodel generator (CR-1) ------------------------------------------------------- Key: HHH-4932 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4932 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0-CR-1 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.5.0-CR-2 -- 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

16 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4908) Multiple failures reported during ReadOnlyProxyTest with Ingres

by Ray Fan (JIRA)

Multiple failures reported during ReadOnlyProxyTest with Ingres --------------------------------------------------------------- Key: HHH-4908 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4908 Project: Hibernate Core Issue Type: Patch Components: testsuite Affects Versions: 3.5.0-Beta-4 Environment: Hibernate 3.5.0-Beta-4, Ingres 9.3.1 Reporter: Ray Fan Priority: Minor Attachments: DataPoint.hbm.xml.diff Failures reported from org.hibernate.test.readonly.ReadOnlyProxyTest in the following tests: {noformat} testReadOnlyViaSessionDoesNotInit testReadOnlyViaLazyInitializerDoesNotInit testReadOnlyViaSessionNoChangeAfterInit testReadOnlyViaLazyInitializerNoChangeAfterInit testReadOnlyViaSessionBeforeInit testModifiableViaSessionBeforeInit testReadOnlyViaSessionBeforeInitByModifiableQuery testReadOnlyViaSessionBeforeInitByReadOnlyQuery testModifiableViaSessionBeforeInitByModifiableQuery testModifiableViaSessionBeforeInitByReadOnlyQuery testReadOnlyViaLazyInitializerBeforeInit testModifiableViaLazyInitializerBeforeInit testReadOnlyViaLazyInitializerAfterInit testModifiableViaLazyInitializerAfterInit testReadOnlyChangedEvictedUpdate testReadOnlyToModifiableInitWhenModifiedIsUpdated testReadOnlyInitToModifiableModifiedIsUpdated testReadOnlyModifiedUpdate testReadOnlyProxyMergeDetachedProxyWithChange testReadOnlyProxyInitMergeDetachedProxyWithChange testReadOnlyProxyMergeDetachedEntityWithChange testReadOnlyProxyInitMergeDetachedEntityWithChange testReadOnlyEntityMergeDetachedProxyWithChange testSetReadOnlyInTwoTransactionsSameSession testSetReadOnlyBetweenTwoTransactionsSameSession testSetModifiableBetweenTwoTransactionsSameSession {noformat} All fail because of an assertion expected:<0.1000000000000000055> but was:<0.10000000000000000550> when run with Ingres 9.3. The DataPoint.hbm.xml description for X and Y specify precision 25 and scale 20 creating the equivalent decimal(25,20) in the Ingres table and returning a zero padded decimal value. Adjusted the scale in the mapping to match expected. -- 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

16 years, 1 month

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4930) Drop org. prefix on hibernate.cache.default_cache_concurrency_strategy and hibernate.id.new_generator_mappings for consistency

by Emmanuel Bernard (JIRA)

Drop org. prefix on hibernate.cache.default_cache_concurrency_strategy and hibernate.id.new_generator_mappings for consistency ------------------------------------------------------------------------------------------------------------------------------ Key: HHH-4930 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4930 Project: Hibernate Core Issue Type: Improvement Components: annotations Affects Versions: 3.5.0-CR-1 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.5.0-CR-2 These two properties declared in AnnotationConfiguration are the only one prefixed with org.hibernate. instead of the standard hibernate. prefix used everywhere else. I am aligning that. -- 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

16 years, 1 month

1
1
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 2010