February 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-35) constraintDescriptor.getConstraintImplementation() is no longer there

by Emmanuel Bernard (JIRA)

constraintDescriptor.getConstraintImplementation() is no longer there --------------------------------------------------------------------- Key: BVAL-35 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-35 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Should we call the ConstraintFactory each time we need an implementation? factory.getInstance( descrptor.getConstraintClass() ); -- 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: (HHH-3749) Only reuse FromElements originatng from from-clause if their aliases match

by Steve Ebersole (JIRA)

Only reuse FromElements originatng from from-clause if their aliases match -------------------------------------------------------------------------- Key: HHH-3749 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3749 Project: Hibernate Core Issue Type: Bug Components: query-hql Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.x, 3.3.x Consider: select ( select clasn1.name from riskClasns_Contxt0.clasn as clasn1 ) as policyType from Risk as risk0 inner join risk0.riskClasns_Contxt as riskClasns_Contxt0 inner join riskClasns_Contxt0.clasn as clasn0 inner join clasn0.clasnScheme as clasnScheme0 Currently we miss the conditions needed in the subquery because we reuse the from element corresponding to riskClasns_Contxt0.clasn from the outer query. Again the solution is to recognize that each has a different alias indicating that we should not reuse the FromElement from the outer query here. -- 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

1
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-105) Rename Past constraint validors

by Alaa Mohssen Nassef (JIRA)

Rename Past constraint validors ------------------------------- Key: BVAL-105 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-105 Project: Bean Validation Issue Type: Patch Components: ri-general Reporter: Alaa Mohssen Nassef Priority: Trivial Attachments: renaming_past_constraint_validators_for_naming_convention.txt Just to comply with the naming convention, I renamed the Past constraint validators -- 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-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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2009