May 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3823) Obtain current revision entity by AuditReader

by Jan Ritzenhoff (JIRA)

Obtain current revision entity by AuditReader --------------------------------------------- Key: HHH-3823 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3823 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Jan Ritzenhoff Implement a new method in the AuditReader class, like: auditReader.getCurrentRevisionEntity(boolean create) The method would return the current revision entity, letting you to fill any of the custom fields. The create parameter would specify if a revision entity should be created, even if no audited entities have been modified. So you dont have to lookup anything in the RevisionListener and you can easy pass some revision-information from the front to the back. Based on forum discussion: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151959 -- 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, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3894) Loader.initializeEntitiesAndCollections() does not guarantee correct behavior of Lifecycle.onLoad()

by Michael Papadopoulos (JIRA)

Loader.initializeEntitiesAndCollections() does not guarantee correct behavior of Lifecycle.onLoad() --------------------------------------------------------------------------------------------------- Key: HHH-3894 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3894 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Michael Papadopoulos Consider lines 871-879 of org.hibernate.loader.Loader (method initializeEntitiesAndCollections()) : if ( hydratedObjects!=null ) { int hydratedObjectsSize = hydratedObjects.size(); if ( log.isTraceEnabled() ) { log.trace( "total objects hydrated: " + hydratedObjectsSize ); } for ( int i = 0; i < hydratedObjectsSize; i++ ) { TwoPhaseLoad.initializeEntity( hydratedObjects.get(i), readOnly, session, pre, post ); } } It is possible that hydratedObjects.get(1) is an entity contained in hydratedObjects.get(0). If hydratedObjects.get(0) implements org.hibernate.classic.Lifecycle, its onLoad() method will be called before the contained entity hydratedObjects.get(1) is initialized, thus breaking the contract of onLoad() (i.e. that onLoad() is called after the entity is loaded; in our case hydratedObjects.get(0) will not be fully loaded yet, since one of its properties will not have been initialized yet). -- 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, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2882) QueryKey.equals() returning false with distributed caching

by Daniel Campagnoli (JIRA)

QueryKey.equals() returning false with distributed caching ---------------------------------------------------------- Key: HHH-2882 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2882 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.5 Reporter: Daniel Campagnoli We noticed some issues recently with the query cache when using Coherence as the cache provider. This was due to instances of org.hibernate.cache.QueryKey not being equal after being serialized then deserialized. The equals check was failing on the [ResultTransformer customTransformer] field which in our case had an instance of RootEntityResultTransformer (which comes from the field CriteriaSpecification.ROOT_ENTITY). This is because RootEntityResultTransformer doesnt override equals, so the check is done by reference equality. When the QueryKey has been serialized and deserialized out of the cache, the instance will always be different, so the equals check will fail. A fix for this to be implement equals for RootEntityResultTransformer (and possibly the other ResultTransformer's). I used the following which worked fine. public boolean equals(Object obj) { return obj != null && this.getClass() == obj.getClass(); } ps. I created HHH-1665 a while ago, a real simple fix, could that be looked at :) -- 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, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-160) Make use of the TraversableResolver contract spliting reachability and cascadability

by Emmanuel Bernard (JIRA)

Make use of the TraversableResolver contract spliting reachability and cascadability ------------------------------------------------------------------------------------ Key: HV-160 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-160 Project: Hibernate Validator Issue Type: New Feature Components: engine Affects Versions: 4.0.0.Beta1 Reporter: Emmanuel Bernard Fix For: 4.0.0.Beta2 -- 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, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-152) TraversableResolver should differentiate reachability and cascadability

by Emmanuel Bernard (JIRA)

TraversableResolver should differentiate reachability and cascadability ----------------------------------------------------------------------- Key: BVAL-152 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-152 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.0 proposed final draft Reporter: Emmanuel Bernard Fix For: 1.0 final /** * Contract determining if a property can be accessed by the Bean Validation provider * This contract is called for each property either validated or traversed. * * A traversable resolver implementation must be thread-safe. * * @author Emmanuel Bernard */ public interface TraversableResolver { /** * Determine if Bean Validation is allowed to reach the property state * * @param traversableObject object hosting <code>traversableProperty</code>, null if validateValue is called * @param traversableProperty name of the traversable property. * @param rootBeanType type of the root object passed to the Validator. * @param pathToTraversableObject path from the root object to * <code>traversableObject</code> ("" if the <code>traversableObject</code> * is the root object) * (using the path specification defined by Bean Validator). * @param elementType either <code>FIELD</code> or <code>METHOD</code>. * * @return <code>true</code> if Bean Validation is allowed to reach the property state, * <code>false</code> otherwise. */ boolean isReachable(Object traversableObject, String traversableProperty, Class<?> rootBeanType, String pathToTraversableObject, ElementType elementType); /** * Determine if Bean Validation is allowed to cascade validation on * the bean instance returned by the property value * marked as <code>@Valid</code>. * Note that this method is called only if isReachable returns true for the same set of * arguments and if the property is marked as <code>@Valid</code> * * @param traversableObject object hosting <code>traversableProperty</code>, null if validateValue is called * @param traversableProperty name of the traversable property. * @param rootBeanType type of the root object passed to the Validator. * @param pathToTraversableObject path from the root object to * <code>traversableObject</code> ("" if the <code>traversableObject</code> * is the root object) * (using the path specification defined by Bean Validator). * @param elementType either <code>FIELD</code> or <code>METHOD</code>. * * @return <code>true</code> if Bean Validation is allowed to cascade validation, * <code>false</code> otherwise. */ boolean isCascadable(Object traversableObject, String traversableProperty, Class<?> rootBeanType, String pathToTraversableObject, ElementType elementType); } -- 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, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-146) ValidatorTypeHelper.resolveTypes ignores return value of recursive call

by Eddy Verbruggen (JIRA)

ValidatorTypeHelper.resolveTypes ignores return value of recursive call ----------------------------------------------------------------------- Key: HV-146 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-146 Project: Hibernate Validator Issue Type: Bug Affects Versions: 4.0.0.Alpha3 Reporter: Eddy Verbruggen My Validator classes extend a common superclass, which in turn implements the ConstraintValidator interface. This version of Hibernate Validator can't cope with that class structure due to a little bug in ValidatorTypeHelper.resolveTypes. The last bit of that method calls itself recursively, but ignores returnvalues, so the code always falls through to "return null". else { resolveTypes( resolvedTypes, rawType.getGenericSuperclass() ); for ( Type genericInterface : rawType.getGenericInterfaces() ) { resolveTypes( resolvedTypes, genericInterface ); } } } //else we don't care I think return null; Can it be changed to something like this please: else { Type returnedType = resolveTypes( resolvedTypes, rawType.getGenericSuperclass() ); if ( returnedType != null ) { return returnedType; } for ( Type genericInterface : rawType.getGenericInterfaces() ) { returnedType = resolveTypes( resolvedTypes, genericInterface ); if ( returnedType != null ) { return returnedType; } } } } //else we don't care I think return null; The stacktrace is: java.lang.NullPointerException at org.hibernate.validation.util.ValidatorTypeHelper.extractType(ValidatorTypeHelper.java:68) at org.hibernate.validation.util.ValidatorTypeHelper.getValidatorsTypes(ValidatorTypeHelper.java:57) at org.hibernate.validation.engine.ConstraintTree.findMatchingValidatorClass(ConstraintTree.java:163) at org.hibernate.validation.engine.ConstraintTree.getInitalizedValidator(ConstraintTree.java:144) at org.hibernate.validation.engine.ConstraintTree.validateConstraints(ConstraintTree.java:113) at org.hibernate.validation.engine.MetaConstraint.validateConstraint(MetaConstraint.java:126) at org.hibernate.validation.engine.ValidatorImpl.validatePropertyForGroup(ValidatorImpl.java:419) at org.hibernate.validation.engine.ValidatorImpl.validateProperty(ValidatorImpl.java:373) at org.hibernate.validation.engine.ValidatorImpl.validateProperty(ValidatorImpl.java:132) -- 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, 8 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HV-149) ReflectionHelper.containsMethod ignores "is" methods

by Juergen Zimmermann (JIRA)

ReflectionHelper.containsMethod ignores "is" methods ---------------------------------------------------- Key: HV-149 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-149 Project: Hibernate Validator Issue Type: Bug Affects Versions: 4.0.0.Beta1 Reporter: Juergen Zimmermann Line 399 of ReflectionHelper looks as follows: clazz.getMethod( "get" + methodName.substring( 0, 1 ).toUpperCase() + methodName.substring( 1 ) ); However, if you have a boolean property, then the get method requires the prefix "is", e.g. private boolean female; public boolean isFemale() { return female; } // prefix "is", not "get" public void setFemale(boolean female) { this.female = female; } This handling is important for methods being annotated with @AssertTrue and @AssertFalse -- 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, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-107) Implement a Hibernate Core specifc implementation of TraversableResolver

by Hardy Ferentschik (JIRA)

Implement a Hibernate Core specifc implementation of TraversableResolver ------------------------------------------------------------------------ Key: HV-107 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-107 Project: Hibernate Validator Issue Type: Task Components: engine Affects Versions: 4.0.0.Alpha2 Reporter: 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, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-152) ValidatorImpl.collectMetaConstraintsForPath does access properties wo checking the TraversableResolver

by Emmanuel Bernard (JIRA)

ValidatorImpl.collectMetaConstraintsForPath does access properties wo checking the TraversableResolver ------------------------------------------------------------------------------------------------------ Key: HV-152 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-152 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.0.0.Beta1 Reporter: Emmanuel Bernard Fix For: 4.0.0.Beta2 -- 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, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3893) JavaAssist fails to instrument classes that clarify method return type

by Paul Pogonyshev (JIRA)

JavaAssist fails to instrument classes that clarify method return type ---------------------------------------------------------------------- Key: HHH-3893 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3893 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: 3.3.1.GA Reporter: Paul Pogonyshev Priority: Minor Javassist refuses to instrument classes where one or more method clarify return type declared in superclass or interface. This is allowed by Java, so I consider this a bug. Error message given by Javassist is 'duplicate method'. Code is roughly like this: class Base { Base getParent(); } class Inherited extends Base { Inherited getParent(); } -- 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2009