June 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-43) Open API to resolve list of constraints for a given group (resolving group sequences)

by Emmanuel Bernard (JIRA)

Open API to resolve list of constraints for a given group (resolving group sequences) ------------------------------------------------------------------------------------- Key: BVAL-43 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-43 Project: Bean Validation Issue Type: Bug Components: spec-general 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

15 years, 3 months

1
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-19) Clarify when the metadata API is needed

by Emmanuel Bernard (JIRA)

Clarify when the metadata API is needed --------------------------------------- Key: BVAL-19 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-19 Project: Bean Validation Issue Type: Improvement Components: ri-general Reporter: Emmanuel Bernard Priority: Minor I think I will add a note on the chapter describing metadata. If somehow the data can be injected in the bean, it's better to use the runtime validation. If this is not possible, the metadata is helpful. From the spec, JCA or Joe Six-Pack are both clients. -- 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, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-66) Consider using a MessageContext to simplify the MessageResolver API

by Emmanuel Bernard (JIRA)

Consider using a MessageContext to simplify the MessageResolver API ------------------------------------------------------------------- Key: BVAL-66 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-66 Project: Bean Validation Issue Type: Improvement Components: spec-general 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

15 years, 3 months

1
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-9) Turn all raw types into generics

by Emmanuel Bernard (JIRA)

Turn all raw types into generics -------------------------------- Key: BVAL-9 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-9 Project: Bean Validation Issue Type: Bug Components: spec-general Reporter: Emmanuel Bernard Assignee: 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

15 years, 3 months

1
2
0 / 0

[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

15 years, 3 months

1
2
0 / 0

[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, 3 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2936) Unclear warning in the logs from LoadContexts.cleanup: fail-safe cleanup (collections)

by Anders Wallgren (JIRA)

Unclear warning in the logs from LoadContexts.cleanup: fail-safe cleanup (collections) -------------------------------------------------------------------------------------- Key: HHH-2936 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2936 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: MySQL 5.0 Reporter: Anders Wallgren We're seeing warning in our logs from this piece of code, but it's unclear from the warning message whether this indicates a problem in my code or in hibernate itself. The error message should be clarified. -- 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, 3 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3710) Add Valid Time support

by jason shi (JIRA)

Add Valid Time support ---------------------- Key: HHH-3710 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3710 Project: Hibernate Core Issue Type: Improvement Components: envers Affects Versions: 3.4 Reporter: jason shi The envers uses transaction time for revisions (REVTSTMP field in REVINFO table). For many enterprise application, the valid time is more important than the transaction time, especially for those tables require revisions. In the envers_seam_demo, there is a bi-temporal demo, it uses additional query conditions (filter by actualDate), It's too complex for us. hope the valid time can be supported natively -- 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, 3 months

2
2
0 / 0

[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, 3 months

2
1
0 / 0

[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, 3 months

3
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2009