[Hibernate-JIRA] Created: (ANN-798) TransactionTest is leaving some transaction opened after its execution, causing DB2 to hang
by Juraci Paixao Krohling (JIRA)
TransactionTest is leaving some transaction opened after its execution, causing DB2 to hang
-------------------------------------------------------------------------------------------
Key: ANN-798
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-798
Project: Hibernate Annotations
Issue Type: Bug
Environment: DB2 and Annotations branch v3_2_1_GA_CP
Reporter: Juraci Paixao Krohling
The first test to be executed after TransactionTest hangs forever, waiting for some transaction to be closed.
The line 32 for org.hibernate.test.annotations.TestCase is the place where it hangs, so, you can add "getSessions().close()" to the end of testTransactionCommit from TransactionTest to simulate this problem without running multiple tests.
As far as I could find, the transaction is not explicit and is "opened" in the last block of assertions in the test testTransactionCommit, between lines 43 and 50 of TransactionTest. If this part is commented out (or skipped) for DB2, everything else works fine.
I suspect this is a problem with the test case, and that this last part of the test should be skipped for DB2, but as I could not find the exact root cause of this failure, I'll leave this as a bug for now.
--
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, 12 months
[Hibernate-JIRA] Created: (HHH-3621) Assertion failure in MigrationTest
by Juraci Paixao Krohling (JIRA)
Assertion failure in MigrationTest
----------------------------------
Key: HHH-3621
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3621
Project: Hibernate Core
Issue Type: Bug
Components: testsuite
Affects Versions: 3.3.x
Environment: Oracle 9i/Oracle 10g/Sybase 12/MySQL and Branch_3_3
Reporter: Juraci Paixao Krohling
The test testSimpleColumnAddition (org.hibernate.test.schemaupdate.MigrationTest) fails due to an assertion failure.
It seems something related to the environment, but as the tests are running without changes from SVN, it needs to be fixed. The tests are running using to the profiles specified in the "testsuite" maven configuration file.
Stack trace:
junit.framework.AssertionFailedError: expected:<0> but was:<1>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.hibernate.test.schemaupdate.MigrationTest.testSimpleColumnAddition(MigrationTest.java:42)
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:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.hibernate.junit.UnitTestCase.runBare(UnitTestCase.java:63)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
--
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
[Hibernate-JIRA] Created: (HHH-3719) Javassist fails to instrument valid classes in certain cases
by Paul Pogonyshev (JIRA)
Javassist fails to instrument valid classes in certain cases
------------------------------------------------------------
Key: HHH-3719
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3719
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Javassist 3.4.GA (also tested with 3.9.GA)
Reporter: Paul Pogonyshev
Priority: Minor
In certain cases Javassist fails with the following message: "duplicate method: getId in org.hibernate.proxy.HibernateProxy_$$_javassist_0".
I was able to trace the problem down to the following simple case.
public interface Identifiable <Type>
{ Type getId (); }
public interface Entity extends Identifiable <Long>
{ Long getId (); }
public class EntityImpl implements Entity
{
private Long id;
public Long getId ()
{ return id; }
void setId (Long id)
{ this.id = id; }
}
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="EntityImpl"
proxy="Entity">
<id name="id"/>
</class>
</hibernate-mapping>
Note that at least generics in definition of Identifiable interface and specifying proxy interface in the mapping seems important. Easy workaround seems to just not explicitly redefine getId() in Entity interface, i.e. just keep the one (same one) gotten from Identifiable. However, _finding_ this workaround was by no means easy.
As I know, Java compiler removes generics information from compiled code, so the two methods might indeed appear different (i.e. as Objecte getId() and Long getId() correspondingly). Maybe Javassist could just disable duplicate method checks in generated classes for the cases when _both_ methods come from the wrapped class?
I'm not sure this is the right tracker, but I couldn't find one for Javassist.
--
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
[Hibernate-JIRA] Created: (ANN-548) Joins break when using composite primary key classes
by Vincent Jenks (JIRA)
Joins break when using composite primary key classes
----------------------------------------------------
Key: ANN-548
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-548
Project: Hibernate Annotations
Type: Bug
Versions: 3.2.1, 3.2.2
Environment: JBoss 4.0.5.GA w/ Hibernate 3.2.2 and Annoations 3.2.2 (from SVN). Also reproduced w/ JBoss 4.0.5.GA w/ stock annotations, hibernate, and entity manager, unmodified. The attached test-case was run against MSSQL 2000 but is trivial to point at another database. The issue was also reproduced on a OpenEdge Progress 10.1A database.
Reporter: Vincent Jenks
Attachments: CarBean.java, Carz.java, Lotz.java
Joins break when using composite primary key classes
JBoss 4.0.5.GA w/ Hibernate 3.2.2 and Annoations 3.2.2 (from SVN). Also reproduced w/ JBoss 4.0.5.GA w/ stock annotations, hibernate, and entity manager, unmodified. The attached test-case was run against MSSQL 2000 but is trivial to point at another database. The issue was also reproduced on a OpenEdge Progress 10.1A database.
In a case where there are composite keys on one (or each) side of a relationship, Hibernate cannot join the entities together if all of the primary key fields are not used in the relationship.
A (very) simple example, two entities Carz and Lotz (pardon the names, it's simply cars and car lots):
@Entity
@Table(name="car")
public class Carz implements Serializable
{
@Id
private Integer id;
@Column(name="make", nullable=false)
private String make;
@Column(name="model", nullable=false)
private String model;
@Column(name="manufactured", nullable=false)
@Temporal(TemporalType.TIMESTAMP)
private Date manufactured;
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumns //Hibernate docs state that @JoinColumns must be used since Lotz has composite PK, a single @JoinColumn does not deploy anyhow
({
@JoinColumn(name="loc_code", referencedColumnName="loc_code", insertable=false, updatable=false)
})
private Lotz lot;
...........................
}
@Entity
@Table(name="lot")
public class Lotz implements Serializable
{
@EmbeddedId
protected LotzPK lotPK;
@Column(name="name", nullable=false)
private String name;
@Column(name="location", nullable=false)
private String location;
@OneToMany(mappedBy="lot", fetch=FetchType.LAZY, cascade=CascadeType.ALL)
private List<Carz> cars;
...........................
}
@Embeddable
public class LotzPK implements Serializable
{
@Column(name="id", nullable=false)
private Integer id;
@Column(name="loc_code", nullable=false)
private String locCode;
...........................
}
In this case I need a one-to-many relationship on Carz.id = Lotz.locCode. However, there doesn't appear to be a way to do this.
When this is deployed, this exception occurs:
org.hibernate.AnnotationException: Column name id of hqb.model.Lotz not found in JoinColumns.referencedColumnName
at org.hibernate.cfg.annotations.TableBinder.bindFk(TableBinder.java:306)
at org.hibernate.cfg.FkSecondPass.doSecondPass(FkSecondPass.java:64)
at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:433)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:287)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1211)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:154)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:847)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:385)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:126)
at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:264)
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.jboss.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:102)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor263.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
...........................
I can deploy the app if I map both fields in the Lotz PK class like so:
@Entity
@Table(name="car")
public class Carz implements Serializable
{
@Id
private Integer id;
...........................
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumns
({
@JoinColumn(name="loc_code", referencedColumnName="loc_code", insertable=false, updatable=false),
@JoinColumn(name="", referencedColumnName="id", insertable=false, updatable=false) //INCORRECTLY DEFINED RELATIONSHIP!
})
private Lotz lot;
...........................
}
But obviously this is no good, it generates bad SQL at runtime:
/* select
c
from
Carz c
left join
fetch c.lot */ select
carz0_.id as id198_0_,
lotz1_.id as id199_1_,
lotz1_.loc_code as loc2_199_1_,
carz0_.make as make198_0_,
carz0_.model as model198_0_,
carz0_.manufactured as manufact4_198_0_,
carz0_.lot_id as lot5_198_0_,
carz0_.loc_code as loc6_198_0_, --no such column...
lotz1_.name as name199_1_,
lotz1_.location as location199_1_
from
car carz0_
left outer join
lot lotz1_
on carz0_.lot_id=lotz1_.id --oops! Hibernate defaulted a relationship here...
and carz0_.loc_code=lotz1_.loc_code
In reality, this is the SQL I'm trying to achieve, by repairing the above query manually:
select
carz0_.id as id198_0_,
lotz1_.id as id199_1_,
lotz1_.loc_code as loc2_199_1_,
carz0_.make as make198_0_,
carz0_.model as model198_0_,
carz0_.manufactured as manufact4_198_0_,
carz0_.loc_code as loc6_198_0_,
lotz1_.name as name199_1_,
lotz1_.location as location199_1_
from
car carz0_
left outer join
lot lotz1_
on carz0_.loc_code=lotz1_.loc_code
This is consistent w/ the EJB 3.0 spec (and Glassfish+Toplink) but that's only because the spec doesn't define exacltly how to handle this. However, that being said, this seems important enough for Hibernate to be able to manage?
--
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
[Hibernate-JIRA] Created: (HHH-3461) Enhance DialectFactory to support Sybase Adaptive Server Anywhere
by Jason Stern (JIRA)
Enhance DialectFactory to support Sybase Adaptive Server Anywhere
-----------------------------------------------------------------
Key: HHH-3461
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3461
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6.GA, Sybase Adaptive Server Anywhere
Reporter: Jason Stern
Priority: Minor
Currently, the org.hibernate.dialect.DialectFactory class has native support for Sybase Adaptive Server Enterprise (ASE), but throws the following exception when used with Sybase Adaptive Server Anywhere (ASA):
"org.hibernate.HibernateException: Hibernate Dialect must be explicitly set for database: Adaptive Server Anywhere"
I have manually set the dialect for now, but if you could add the following line of code to the DialectFactory class, it would help with future portability:
MAPPERS.put( "Adaptive Server Anywhere", new VersionInsensitiveMapper( "org.hibernate.dialect.SybaseAnywhereDialect" ) );
Thanks for all your hard work!
--
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
[Hibernate-JIRA] Created: (HHH-3731) ConstraintViolationException logged at level ERROR instead of WARN or INFO
by Jonathan Amir (JIRA)
ConstraintViolationException logged at level ERROR instead of WARN or INFO
--------------------------------------------------------------------------
Key: HHH-3731
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Environment: hibernate core jar specifies 3.2.6 in META-INF folder. database is oracle 10.2. OS is Win XP
Reporter: Jonathan Amir
Priority: Minor
Attachments: stacktrace.txt
Please see this thread for an example and an explanation of the problem:
http://forums.hibernate.org/viewtopic.php?p=2258025&sid=cdcf98f3e9026fad9...
Basically, it is a valid use-case for a developer to insert a record to the db and to try and catch a ConstraintViolationException. Upon catching it, it should be the developer's choice regarding what to do, how to recover, etc., and also how to log it.
However, Hibernate logs the error before throwing it, and at log level ERROR, no less, thus polluting the log files with superfluous messages. It is not practical to log messages at this Level. The offending class is AbstractFlushingEventListener.java (I'm attaching a stacktrace to illustrate).
Please reduce the log level of this message to WARN or INFO.
There's also a sort of philosophical argument for this request. Some may argue, like in the reply in the linked thread above, that a constraint violation is an error, thus it should be logged as one. However, that is an application-domain error, not a hibernate error. Hibernate is a library, and as such it should conform to user's requirements. First, it should use the ERROR level only to log real errors related to Hibernate's functionality as a library. Secondly, it should aim to give the user maximum flexiblity and control with regards to logging.
(Not withstanding the previous statement, logging application problems is, of course, very helpful for debugging, but it should be at a lower log level)
--
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