July 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-218) Offer contract to validate method parameters and return values

by Emmanuel Bernard (JIRA)

Offer contract to validate method parameters and return values -------------------------------------------------------------- Key: BVAL-218 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-218 Project: Bean Validation Issue Type: New Feature 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

14 years, 6 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-666) Get documentation onto translate.jboss.org

by Hardy Ferentschik (JIRA)

Get documentation onto translate.jboss.org ------------------------------------------ Key: HSEARCH-666 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-666 Project: Hibernate Search Issue Type: Task Components: build, documentation Affects Versions: 3.3.0.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.4.0 See also HV-416 -- 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, 6 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3248) org.hibernate.cache.EhCache.toMap() throws NullPointerException

by Kenny MacLeod (JIRA)

org.hibernate.cache.EhCache.toMap() throws NullPointerException --------------------------------------------------------------- Key: HHH-3248 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3248 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Reporter: Kenny MacLeod The toMap() method of org.hibernate.cache.EhCache is not null-safe. The expression cache.get( key ).getObjectValue() Will throw a NPE, since get(key) may return a null in cases where the key exists in the cache, but the value does not, e.g. if it has expired. This should either check for the null, or the list of keys should be obtained using getKeysWithExpiredCheck(), rather than just getKeys(). -- 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, 6 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5326) UpdateTimestampsCache should maintain the statistics for its region

by Alex Snaps (JIRA)

UpdateTimestampsCache should maintain the statistics for its region ------------------------------------------------------------------- Key: HHH-5326 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5326 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Alex Snaps Don't know if it is by design, but the SecondLevelCacheStatistics' for the UpdateTimestampsCache region are not maintained. Any idea why ? -- 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, 6 months

3
8
0 / 0

[Hibernate-JIRA] Created: (BVAL-213) Convert persistence storage exception into Bean Validation exceptions

by Emmanuel Bernard (JIRA)

Convert persistence storage exception into Bean Validation exceptions --------------------------------------------------------------------- Key: BVAL-213 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-213 Project: Bean Validation Issue Type: New Feature Components: spec-general Reporter: Emmanuel Bernard This is not a problematic of Bean Validation per se but one of the issue people are facing is inconsistency in constraint reporting. For example, the database can raise a some kind of unique constraint exception (specific to each vendor usually). It would be ideal to get it converted into a @Unique constraint exception as defined by Bean Validation. Said differently by Christian {code}I'd rather see improvement of message propagation/mapping when an integrity rule inside the database has been violated. Like, turning a fatal database transaction exception (JDBCException wrapped etc.) into a clean error message, with a strong and stable mapping across DBMS products. If a UNIQUE constraint has been violated at the database level, I'd like to catch it and turn it into a Bean Validation error for my client. We have discussed this >5 years ago and at that time there was just no way to really guarantee that a JDBCException can tell you what the real cause of the problem was. Nobody standardized or required that the catalog name of the violated constraint is included so you couldn't map it. Maybe that's possible now. If not, at least the generic ConstraintViolationException should be an SPI of Bean Validation that JPA providers can throw.{code} -- 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, 6 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-215) Make composition more flexible (OR support)

by Emmanuel Bernard (JIRA)

Make composition more flexible (OR support) ------------------------------------------- Key: BVAL-215 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-215 Project: Bean Validation Issue Type: New Feature Components: spec-general Reporter: Emmanuel Bernard http://opensource.atlassian.com/projects/hibernate/browse/HV-390 -- 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, 6 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-229) Offer a programmatic API to declare constraints on a domain model

by Emmanuel Bernard (JIRA)

Offer a programmatic API to declare constraints on a domain model ----------------------------------------------------------------- Key: BVAL-229 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-229 Project: Bean Validation Issue Type: New Feature 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

14 years, 6 months

3
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-226) Make clear whether the static or the runtime type should be considered when creating property paths in case of cascaded validations

by Gunnar Morling (JIRA)

Make clear whether the static or the runtime type should be considered when creating property paths in case of cascaded validations ----------------------------------------------------------------------------------------------------------------------------------- Key: BVAL-226 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-226 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.0 final Reporter: Gunnar Morling Fix For: 1.1 As of version 1.0 the specification does not clearly state, whether the static or the runtime type of an association should be considered when creating property paths in case of cascaded validations. Let there be the following type: {code:java} class Foo { private Collection<Bar> bar1 = new ArrayList<Bar>(); private List<Bar> bar2 = new ArrayList<Bar>(); } {code} When validating an instance of Foo (which has invalid elements in bar1/bar2) with the RI, the resulting property path node for bar1 would be iterable but not indexable ("bar1[]"), while the property path node for bar2 would be iterable and indexable ("bar2[123]"). This is that way because the static type of bar1/bar2 (Collection vs. List) is considered by the RI when building the nodes, and not the runtime type (ArrayList in both cases). According to a post [1] on the Hibernate Validator forum Apache's JSR 303 implementation follows the runtime type approach. This seems reasonable to me, too (as for instance the constraints to validate are also determined based on the runtime type of references). The specification should make clear what the intended behavior is and provide a TCK test case. [1] related forum post: https://forum.hibernate.org/viewtopic.php?f=9&t=1010626 [2] related discussion on hibernate-dev: http://lists.jboss.org/pipermail/hibernate-dev/2011-April/006359.html -- 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, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6162) SessionFactory in QueryKey

by Pawel Omelko (JIRA)

SessionFactory in QueryKey -------------------------- Key: HHH-6162 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6162 Project: Hibernate Core Issue Type: Bug Affects Versions: 4.0.0.Alpha2, 3.6.3, 4.0.0.Alpha1, 3.6.2 Environment: Hibernate 3.6.2, Postgresql 8.3 Reporter: Pawel Omelko Priority: Blocker I guess that after improvement HHH-5138, a ManyToOneType.java (and many other types) has reference to SessionFactory (by TypeFactory.TypeScope scope field). And now QueryKey, which contains Type[] positionalParameterTypes field, contains also SessionFactory - eg. ManyToOneType. So now we can find SessionFactory in QueryCache elements, which unnecessarily increase memory usage. There is another problem when cache replication is used (ehcache via RMI), I've got an exception during SessionFactory deserialization in receiver node: Apr 27 06:17:58 WARN net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator:320 - Unable to send message to remote peer. Message was: null Apr 27 06:17:58 java.lang.NullPointerException Apr 27 06:17:58 at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) Apr 27 06:17:58 at org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159) Apr 27 06:17:58 at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753) Apr 27 06:17:58 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Apr 27 06:17:58 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) Apr 27 06:17:58 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Apr 27 06:17:58 at java.lang.reflect.Method.invoke(Method.java:597) Apr 27 06:17:58 at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061) Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762) Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) Apr 27 06:17:58 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) Apr 27 06:17:58 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) Apr 27 06:17:58 at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480) Apr 27 06:17:58 at org.hibernate.cache.QueryKey.readObject(QueryKey.java:192) -- 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, 6 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5938) Entities with compound primary keys are not properly handled when querying metamodel and using Criteria API

by Jaroslaw Lewandowski (JIRA)

Entities with compound primary keys are not properly handled when querying metamodel and using Criteria API ----------------------------------------------------------------------------------------------------------- Key: HHH-5938 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5938 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.0 Reporter: Jaroslaw Lewandowski Suppose we have entity defined like this: {code} @Entity class Foo { @Id Long first; @Id Long second; .... } {code} Then the following code will fail: {code} Metamodel mm = entityManager.getMetamodel(); EntityType<Foo> foo_ = mm.entity(Foo.class); foo_.getSingularAttribute("first", Long.class); foo_.getSingularAttribute("second", Long.class); {code} The same problems exists trying to query this entity: {code} CriteriaBuilder cb = entityManager.getMetamodel(); CriteriaQuery<Foo> cq = cb.createQuery(Foo.class); Root<Foo> foo = cq.from(Foo.class); cq.where(cb.equal(foo.get("first"), 1L), cb.equal(foo.get("second"), 2L)); {code} See that attributes are accessed by name. In the first example IllegalArgumentException is thrown in second NPE -- 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, 6 months

2
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2011