November 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-925) Upgrade to JGroups 3

by Sanne Grinovero (JIRA)

Upgrade to JGroups 3 -------------------- Key: HSEARCH-925 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-925 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero JGroups3 is an API update, and version 3 is the one being used by newest versions of JBossAS and Infinispan so we need to upgrade. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5356) Sybase 15 does not support cross join

by Alexis Kofman (JIRA)

Sybase 15 does not support cross join ------------------------------------- Key: HHH-5356 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5356 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.3 Environment: Hibernate 3.5.3-Final, Sybase 15.0.3 ASE Reporter: Alexis Kofman Priority: Minor It seems cross join is not yet implemented in Sybase. However the implemented Sybase 15 ASE Dialect in Hibernate use this kind of join : SybaseASE15Dialect is a subsubclass of Dialect in which we can find : public String getCrossJoinSeparator() { return " cross join "; } A workaround is to override this method as it is done in Sybase11Dialect. -- 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, 3 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5948) Trying to get a PluralAttributePath from a @MappedSuperclass throws org.hibernate.MappingException: Unknown collection role

by Oliver Ringel (JIRA)

Trying to get a PluralAttributePath from a @MappedSuperclass throws org.hibernate.MappingException: Unknown collection role ---------------------------------------------------------------------------------------------------------------------------- Key: HHH-5948 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5948 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.1, 3.6.0 Reporter: Oliver Ringel Attachments: testcase-hibernate.tgz I'm trying to get the PluralAttributePath from a collection defined in a MappedSuperclass @Entity public class Person extends PersonBase { @Basic private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } @MappedSuperclass public abstract class PersonBase { @Id private String id; public String getId() { return id; } public void setId(String id) { this.id = id; } @OneToMany() private Set<Address> addresses = new HashSet<Address>(); public Set<Address> getAddresses() { return addresses; } public void setAddresses(Set<Address> addresses) { this.addresses = addresses; } } Executing the following criteriaQuery = criteriaBuilder.createQuery(Person.class); root = criteriaQuery.from(Person.class); Path<?> pathAddresses = root.get("addresses"); throws the exception org.hibernate.MappingException: Unknown collection role: testcase.hibernate.PersonBase.addresses at org.hibernate.impl.SessionFactoryImpl.getCollectionPersister(SessionFactoryImpl.java:701) at org.hibernate.ejb.criteria.path.PluralAttributePath.resolvePersister(PluralAttributePath.java:58) at org.hibernate.ejb.criteria.path.PluralAttributePath.<init>(PluralAttributePath.java:52) at org.hibernate.ejb.criteria.path.AbstractPathImpl.get(AbstractPathImpl.java:157) at org.hibernate.ejb.criteria.path.AbstractPathImpl.get(AbstractPathImpl.java:197) at testcase.hibernate.HibernateTest.testMappedSuperclassPluralAttribute(HibernateTest.java:53) -- 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, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5124) Removing an entity and persisting it again fails

by Jesper Steen Møller (JIRA)

Removing an entity and persisting it again fails ------------------------------------------------ Key: HHH-5124 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5124 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.x, 3.5.x Environment: Tested with Hibernate 3.3.2, HSQL 1.7.2 Reporter: Jesper Steen Møller Attachments: RemoveAndPersistProblem.zip According to the JPA spec section 3.2.1, it should be possible to remove and then (re)persist an entity, but Hibernate will throw an javax.persistence.EntityNotFoundException: deleted entity passed to persist, originating from DefaultPersistEventListener.onPersist, in the 'default'-case of the switch for entityState. The code in question is not changed between 3.3.2 and 3.5.1, so it should have the same problem. The enclosed test project (Eclipse project format, just add all the usual jars + hsql) demonstrates the problem. Also see https://forum.hibernate.org/viewtopic.php?f=1&t=995703&view=previous -- 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, 3 months

3
24
0 / 0

[Hibernate-JIRA] Created: (HV-512) Composed constraints lose the payload information of the constraints they are composed of

by Geoff The (JIRA)

Composed constraints lose the payload information of the constraints they are composed of ----------------------------------------------------------------------------------------- Key: HV-512 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-512 Project: Hibernate Validator Issue Type: Bug Components: validators Affects Versions: 4.2.0.Final Reporter: Geoff The If a payload is set for child constraints in a composed constraint, their payload values will be ignored. HV-183 dealt with the propagation of the parent's payload down to the children constraints, but it also overwrites any payload the children may have had. I would suggest that if the children have any explicit payloads defined, they should be integrated into the parents and not blown away. {code} import org.junit.*; import javax.validation.*; import javax.validation.constraints.NotNull; import java.lang.annotation.*; import java.util.*; import static org.junit.Assert.*; import static java.lang.annotation.ElementType.*; import static java.lang.annotation.RetentionPolicy.*; public class TestPayload { public static class Warning implements Payload {} public static class Error implements Payload {} @Documented @Constraint(validatedBy = NameMustBeGeoffValidator.class) @Target({ TYPE, METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER }) @Retention(RUNTIME) public @interface NameMustBeGeoff { String message() default "{NameMustBeGeoff.message}"; Class<?>[] groups() default {}; Class<? extends Payload>[] payload() default {}; } public static class NameMustBeGeoffValidator implements ConstraintValidator<NameMustBeGeoff, Customer> { @Override public void initialize(NameMustBeGeoff constraintAnnotation) {} @Override public boolean isValid(Customer value, ConstraintValidatorContext context) { return ((value.getName() == null) || (value.getName().equals("Geoff"))); } } @NameMustBeGeoff(payload = Error.class) @Documented @Constraint(validatedBy = ValidCustomerValidator.class) @Target({ TYPE, METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER }) @Retention(RUNTIME) public @interface ValidCustomer { String message() default "{ValidCustomer.message}"; Class<?>[] groups() default {}; Class<? extends Payload>[] payload() default {}; } public static class ValidCustomerValidator implements ConstraintValidator<ValidCustomer, Customer> { @Override public void initialize(ValidCustomer constraintAnnotation) {} @Override public boolean isValid(Customer value, ConstraintValidatorContext context) { return true; } } @ValidCustomer public class Customer { private String name; public Customer(String name) { this.name = name; } @NotNull(payload = Warning.class) public String getName() { return this.name; } } /** * Customer's name is null, it should trigger the @NotNull with a Warning payload */ @Test public void test() { ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Customer customer = new Customer(null); Set<ConstraintViolation<Customer>> violations = validator.validate(customer); assertEquals(1, violations.size()); ConstraintViolation<Customer> violation = violations.iterator().next(); assertEquals("may not be null", violation.getMessage()); assertEquals("javax.validation.constraints.NotNull", violation.getConstraintDescriptor().getAnnotation().annotationType().getName()); assertEquals(1, violation.getConstraintDescriptor().getPayload().size()); assertEquals(Warning.class, violation.getConstraintDescriptor().getPayload().iterator().next()); } /** * Customer's name is not Geoff and should trigger the NameMustBeGeoff constraint, but the Error payload is lost */ @Test public void testPayloadInComposedConstraints() { ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Customer customer = new Customer("Bob"); Set<ConstraintViolation<Customer>> violations = validator.validate(customer); assertEquals(1, violations.size()); ConstraintViolation<Customer> violation = violations.iterator().next(); assertEquals("{NameMustBeGeoff.message}", violation.getMessage()); assertEquals("org.geofft.TestPayload$NameMustBeGeoff", violation.getConstraintDescriptor().getAnnotation().annotationType().getName()); assertEquals(0, violation.getConstraintDescriptor().getPayload().size()); // Not what I expected /* What I think should happen: assertEquals(1, violation.getConstraintDescriptor().getPayload().size()); assertEquals(Customer.Error.class, violation.getConstraintDescriptor().getPayload().iterator().next()); */ } } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-981) Upgrade to Lucene 3.5

by Sanne Grinovero (JIRA)

Upgrade to Lucene 3.5 --------------------- Key: HSEARCH-981 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-981 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 4.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5684) Change Javassist usage to not use javassist.util.proxy.ProxyFactory

by Steve Ebersole (JIRA)

Change Javassist usage to not use javassist.util.proxy.ProxyFactory ------------------------------------------------------------------- Key: HHH-5684 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5684 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Fix For: 4.0.0.Alpha2 javassist.util.proxy.ProxyFactory maintains a cache of proxy classes generated. Apparently it does this based on a static variable. First and foremost, this cache is completely unnecessary given how Hibernate creates and uses these proxy classes. Second there is some conjecture that this might possibly contribute to permgen leaks. -- 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, 3 months

1
12
0 / 0

[Hibernate-JIRA] Created: (HHH-5688) Migrate BytecodeProvider to be a Service

by Steve Ebersole (JIRA)

Migrate BytecodeProvider to be a Service ---------------------------------------- Key: HHH-5688 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5688 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.Alpha1 This is deeply dependent upon the metamodel redesign completion. -- 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, 3 months

2
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-638) Limit graph traversal by @ContainedIn to the minimum required path

by Sanne Grinovero (JIRA)

Limit graph traversal by @ContainedIn to the minimum required path ------------------------------------------------------------------ Key: HSEARCH-638 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-638 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.2.1, 3.2.0.Final, 3.1.1.GA, 3.1.0.GA, 3.3.0 Reporter: Sanne Grinovero Unit test available in the source tree since HSEARCH-513 org.hibernate.search.test.embedded.depth.RecursiveGraphTest, see the "FIXME" referring to this issue. It seems that @ContainedIn is now traversing the graph "upwards" towards any related entity it might find, without any limit; this happens to work pretty well in most simple use cases but becomes a performance problem in the more complex scenarios. -- 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, 3 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HHH-6606) org.hibernate.metamodel.source.annotations.util.EmbeddableHierarchyTest#testEmbeddableHierarchy fails on openjdk

by Strong Liu (JIRA)

org.hibernate.metamodel.source.annotations.util.EmbeddableHierarchyTest#testEmbeddableHierarchy fails on openjdk ---------------------------------------------------------------------------------------------------------------- Key: HHH-6606 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6606 Project: Hibernate Core Issue Type: Bug Components: metamodel Affects Versions: 4.0.0.CR1 Reporter: Strong Liu Assignee: Hardy Ferentschik Fix For: 4.0.0.next Hardy, i'm assigning this to you since you wrote this test :) {code} junit.framework.AssertionFailedError: wrong class expected:<org.hibernate.metamodel.source.annotations.util.EmbeddableHierarchyTest$1A> but was:<org.hibernate.metamodel.source.annotations.util.EmbeddableHierarchyTest$1C> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:283) at junit.framework.Assert.assertEquals(Assert.java:64) at org.hibernate.metamodel.source.annotations.util.EmbeddableHierarchyTest.testEmbeddableHierarchy(EmbeddableHierarchyTest.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:63) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.hibernate.testing.junit4.FailureExpectedHandler.evaluate(FailureExpectedHandler.java:59) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.hibernate.testing.junit4.BeforeClassCallbackHandler.evaluate(BeforeClassCallbackHandler.java:43) at org.hibernate.testing.junit4.AfterClassCallbackHandler.evaluate(AfterClassCallbackHandler.java:42) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:51) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:63) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49) at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:75) at $Proxy3.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:86) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.messaging.remote.internal.MethodInvocationUnmarshallingDispatch.dispatch(MethodInvocationUnmarshallingDispatch.java:48) at org.gradle.messaging.dispatch.DiscardOnFailureDispatch.dispatch(DiscardOnFailureDispatch.java:31) at org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:129) at org.gradle.messaging.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33) at org.gradle.messaging.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:69) at org.gradle.messaging.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:63) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
7
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 November 2011