January 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3744) Improved support for persistence of subclasses

by Ben Clark (JIRA)

Improved support for persistence of subclasses ---------------------------------------------- Key: HHH-3744 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3744 Project: Hibernate Core Issue Type: Patch Components: envers Environment: hibernate-envers-3.4.0-SNAPSHOT, hibernate-core-3.4.0-SNAPSHOT, hibernate-annotations-3.4.0-SNAPSHOT, not hibernate entity manager, hsqldb 1.8.0 Reporter: Ben Clark Priority: Minor Attachments: envers-patch.txt I've been trying to use envers to add auditing functionality to an existing application and found a few minor bugs in the way which it persisted subclasses, and their properties. All were mapped with table-per-class-hierarchy. Also, there were some issues relating to hibernate proxies, where getClass() was returning the name of the enhanced class, not the actual class, or where session.guessEntityName() returned the name of the (proxied) superclass, not the actual class. I also ran into a NPE when persisting a subclass where the changes were in collections belonging to the superclass, and another problem with access to private constructors which I think is already flagged as an issue. I've attached a patch which resolves these issues, but it results in failures in the following tests: testHistoryOfId, testRevisionsCounts Thanks, Ben -- 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, 11 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3736) Envers EntityInstantiator does not support private constructors for immutable entities

by Erik-Berndt Scheper (JIRA)

Envers EntityInstantiator does not support private constructors for immutable entities -------------------------------------------------------------------------------------- Key: HHH-3736 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3736 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.4 Reporter: Erik-Berndt Scheper Hibernate supports the use of private constructors in JPA, which is typically used for immutable entities. Auditing of these entities works perfectly fine. However, retrieving audit records using getAuditReader().find leads to an IllegalAccessException in org.hibernate.envers.entities.EntityInstantiator See attached test case to reproduce this. Stack trace: org.hibernate.envers.exception.AuditException: java.lang.IllegalAccessException: Class org.hibernate.envers.entities.EntityInstantiator can not access a member of class org.hibernate.envers.ebstest.entities.Country with modifiers "private" at org.hibernate.envers.entities.EntityInstantiator.createInstanceFromVersionsEntity(EntityInstantiator.java:85) at org.hibernate.envers.entities.EntityInstantiator.addInstancesFromVersionsEntities(EntityInstantiator.java:102) at org.hibernate.envers.query.impl.EntitiesAtRevisionQuery.list(EntitiesAtRevisionQuery.java:90) at org.hibernate.envers.query.impl.AbstractAuditQuery.getSingleResult(AbstractAuditQuery.java:104) at org.hibernate.envers.reader.AuditReaderImpl.find(AuditReaderImpl.java:103) at org.hibernate.envers.ebstest.integration.accesstype.ImmutableFieldAccessType.testHistoryOfId1(ImmutableFieldAccessType.java:50) 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 org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580) at org.testng.internal.Invoker.invokeMethod(Invoker.java:478) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:617) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:885) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110) at org.testng.TestRunner.runWorkers(TestRunner.java:712) at org.testng.TestRunner.privateRun(TestRunner.java:582) at org.testng.TestRunner.run(TestRunner.java:477) at org.testng.SuiteRunner.runTest(SuiteRunner.java:324) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:319) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:292) at org.testng.SuiteRunner.run(SuiteRunner.java:198) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:823) at org.testng.TestNG.runSuitesLocally(TestNG.java:790) at org.testng.TestNG.run(TestNG.java:708) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124) Caused by: java.lang.IllegalAccessException: Class org.hibernate.envers.entities.EntityInstantiator can not access a member of class org.hibernate.envers.ebstest.entities.Country with modifiers "private" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) at java.lang.Class.newInstance0(Class.java:344) at java.lang.Class.newInstance(Class.java:303) at org.hibernate.envers.entities.EntityInstantiator.createInstanceFromVersionsEntity(EntityInstantiator.java:83) ... 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

15 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-70) default MessageResolver is instanciated in Validator<T>, it should not

by Emmanuel Bernard (JIRA)

default MessageResolver is instanciated in Validator<T>, it should not ---------------------------------------------------------------------- Key: BVAL-70 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-70 Project: Bean Validation Issue Type: Improvement Components: ri-general Reporter: Emmanuel Bernard Seems to be a left over from a previous life. The default MR is instanciated by the VFBuilder and passed to the VF. That's the only area it should be instanciated. -- 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-2) Is there a difference between the implicit default group given by {} and the explcitly specified group "default"?

by Hardy Ferentschik (JIRA)

Is there a difference between the implicit default group given by {} and the explcitly specified group "default"? ----------------------------------------------------------------------------------------------------------------- Key: BVAL-2 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-2 Project: Bean Validation Issue Type: Task Components: spec-general Reporter: Hardy Ferentschik The question is why is the the default value for groups not "default" instead of the empty array? I think the it would be more explicit to use "default". Also if I do not specify a group and hence the default (empty array) applies, what does the corresponding ConstraintDescriptor.getGroups() return? An empty array or "default"? Or are we saying that the default group is to be treated separately from the explicitly specified group 'default'? Emmanuel's reasoning behind the empty array was to keep it simple for annotation developers, one less thing to remember and typo to do. However, if we decide to treat the empty array and "default' the same way, I would opt for a explicit "default" string. -- 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, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-18) Validator<A>.validate(b) where b:B and B extends A should validate B. Metadata APIs are specific to A

by Emmanuel Bernard (JIRA)

Validator<A>.validate(b) where b:B and B extends A should validate B. Metadata APIs are specific to A ----------------------------------------------------------------------------------------------------- Key: BVAL-18 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-18 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-27) Avoid the use of raw types including in the test suite as much as possible

by Emmanuel Bernard (JIRA)

Avoid the use of raw types including in the test suite as much as possible -------------------------------------------------------------------------- Key: BVAL-27 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-27 Project: Bean Validation Issue Type: Improvement Components: ri-general Reporter: Emmanuel Bernard eg ValidatorBuilder rather than ValidatorBuilder<?> -- 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-16) Has the property passed to validator.validateProperty() be reachable by a valid chain of validation.

by Hardy Ferentschik (JIRA)

Has the property passed to validator.validateProperty() be reachable by a valid chain of validation. ---------------------------------------------------------------------------------------------------- Key: BVAL-16 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-16 Project: Bean Validation Issue Type: Task Components: ri-general, spec-general Reporter: Hardy Ferentschik if you do something like this validateProperty( foo, "prop1.prop2.prop3[3]" ), does this imply that the whole chain is validated? One could just get the value/class for prop[3] and see if there are any validations defined on it or you could actually traverse the whole path and also ensure that prop1 and prop2 are annotated with @Valid. To put it differently, has the property to validated be reachable via a valid 'validation chain'? Somehow it feels to be the right thing to do. -- 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, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-10) Turn ValidatorParser into a MetadataProvider

by Emmanuel Bernard (JIRA)

Turn ValidatorParser into a MetadataProvider -------------------------------------------- Key: BVAL-10 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-10 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik You should turn parser into something more like a MetadataProvider. I removed the getValidators() method from parser and moved it to ValidatorImpl. The parser should not be aware of ValidatorImpl, nor Validator for that matter. The MetadataProvider will be an interface anybody can implement. We will do the annotation version as well as the XML version (and probably some kind of XML overriding annotation version) but one can imagine a Script / Groovy DSLed version, a Programmatic API version and so on. I imagine a MetadataProvider instance can be passed during the building phase to the ValidatorFactory. The same instance would then be shared for all Validators (kind of make sense, you can't parse XML for every single ValdiatorImpl instantiation). That woul mean the parser ode needs ot be reworked to be immutable (at least work in concurrent calls) -- 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, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-31) Constraint composition

by Emmanuel Bernard (JIRA)

Constraint composition ---------------------- Key: BVAL-31 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-31 Project: Bean Validation Issue Type: New Feature 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, 11 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3357) session.clear() takes too long

by Jay Erb (JIRA)

session.clear() takes too long ------------------------------ Key: HHH-3357 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3357 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.6, 3.2.5 Reporter: Jay Erb Clearing a session that contains a large number of Proxies takes a very long time. The reason for this is that null is set on the LazyInitializer when clearing the StatefulPersistenceContext, whenever a new session is set on an AbstractLazyInitializer, a check is done to see if the AbstractLazyInitializer is still attached to its previous session (and correctly throws an exception if it is). This check performs a linear search through all Proxies in the PersistenceContext. Since we're setting the session to null, do we really need to do this expensive linear search? I propose we not perform the linear search if the session being set on the AbstractLazyInitializer is null. -- 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, 11 months

5
13
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2009