December 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3427) executeUpdate never completes

by Mojmir Tuljak (JIRA)

executeUpdate never completes ----------------------------- Key: HHH-3427 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3427 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.0.ga Environment: Hibernate 3.2.0 ga, Oracle 10.2.0.1.0, JAVA 1.6 Reporter: Mojmir Tuljak Update (query.executeUpdate()) never completes. Using oracle enterprise manager we can see that oracle has completed the update but method executedUpdate() never returned any result so the application is waiting. The problem is not always reproducable and happens once or twice a day, always when the same executeUpdate is called while the previous one is still in progress. No exception is thrown. Executing the same query directly without the use of hibernate does not lead to the above problems. -- 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

17 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2310) LazyInitializationException: Initializing many-to-one and one-to-one associations to a maximum of max-fetch-depth fails when using a SQLProjection on a Criteria generated Query

by Nico De Groote (JIRA)

LazyInitializationException: Initializing many-to-one and one-to-one associations to a maximum of max-fetch-depth fails when using a SQLProjection on a Criteria generated Query -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2310 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2310 Project: Hibernate3 Type: Bug Components: core Versions: 3.0.5 Reporter: Nico De Groote Priority: Critical Initializing many-to-one and one-to-one associations to a maximum of max-fetch-depth fails when using a SQLProjection on a Criteria generated Query Following scenario occurs. I have a max-fetch-depth = default value. I have a the following businessobject having the following associations. BO -> BO2 (One to one) BO -> list of BO3 (one to many) I want to query for BO objects with the where clause containing a condition on one of the properties of the BO3 objects. When I now generate my query via the Criteria API and having the following projection set to retrieve only my BO objects (and none of the outer joinables) Projection projection = Projections.sqlProjection( "{alias}." + primaryKeyColumn + " theObj__", new String[]{"theObj__"}, new Type[]{Hibernate.entity(BO.getClass())}); I get my BO objects but the BO2 object is not initialized, as it should ne because of the max-fetch-depth. When not using the Projection I do get the one-to-one relation (BO2 object) as the max-fetch-depth is default value, but the query takes too much time because of the non required properties for the outerjoinable associations in the select clause. It seams that the fetching of the many-to-one and the one-to-one associations for the max-fetch-depth is disabled when using projections. Or am I missing the point 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

17 years, 3 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HV-61) Message bundles are not used when validating nested abstract classes

by Christian Blavier (JIRA)

Message bundles are not used when validating nested abstract classes -------------------------------------------------------------------- Key: HV-61 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-61 Project: Hibernate Validator Issue Type: Bug Affects Versions: 3.0.0.ga Environment: No hibernate, no database Reporter: Christian Blavier Priority: Critical Attachments: hibernate-validator-issue.zip Hi, I got a problem : when validating nested abstract instances, my message bundles are not used (default Hibernate-validator messages are used instead) You can find attached a testcase that reproduces the problem (it is normal that the test fails, it's the issue) Thanks for your help, -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-703) @Past and @Future should support inclusive and exclusive boundaries

by Dan Allen (JIRA)

@Past and @Future should support inclusive and exclusive boundaries ------------------------------------------------------------------- Key: ANN-703 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-703 Project: Hibernate Annotations Issue Type: Improvement Components: validator Affects Versions: 3.3.1.CR1 Reporter: Dan Allen Fix For: 3.3.1 The @Future and @Past annotations do not offer a way to include the current date in the range, operating under the pretense of an exclusive boundary condition. The current date is often needed in the range. For instance, a registration date can be today or any time in the future. You might have recorded an observation today or any time in the past. My suggestion is to add an attribute named "inclusive" which implies that the current date is included. @Future(inclusive = true) @Past(inclusive = true) Feel free to use another name for the attribute. The default, of course, is false for backwards compatibility. -- 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

17 years, 3 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HV-69) DefaultValidatorMessages_de.properties not correct

by Juergen Zimmermann (JIRA)

DefaultValidatorMessages_de.properties not correct -------------------------------------------------- Key: HV-69 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-69 Project: Hibernate Validator Issue Type: Bug Affects Versions: 3.1.0.CR2 Reporter: Juergen Zimmermann These 2 properties are not translated: validator.email=not a well-formed email address validator.digits=numeric value out of bounds (<{integerDigits} digits>.<{fractionalDigits} digits> expected) Suggestion: validator.email=ist keine gültige EMail-Adresse validator.digits=keine zulässige Zahl(<{integerDigits} Ziffern>.<{fractionalDigits} Ziffern> sind zulässig) -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-62) Embedded class used twice in a Entity, once validating and another don't.

by Raoni Fortes Normanton (JIRA)

Embedded class used twice in a Entity, once validating and another don't. ------------------------------------------------------------------------- Key: HV-62 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-62 Project: Hibernate Validator Issue Type: Bug Affects Versions: 3.0.0.ga Environment: Running with: <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-annotations</artifactId> <version>3.3.0.ga</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-validator</artifactId> <version>3.0.0.GA</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-entitymanager</artifactId> <version>3.3.1.ga</version> </dependency> Reporter: Raoni Fortes Normanton Attachments: Address.java, Customer.java, CustomerTest.java My Customer class has two address (embedded), one must be validated, the other dont. When the address2 is null, the validation works. But when the empty instance is setted, the persist crashes. Validating by ClassValidator works fine. But when I call the em.persist() in service, the exception is throwed: javax.ejb.EJBException: nested exception is: org.hibernate.validator.InvalidStateException: validation failed for: br.com.kinomaxx.kinosystem.Customer org.hibernate.validator.InvalidStateException: validation failed for: br.com.kinomaxx.kinosystem.Customer at org.hibernate.validator.event.ValidateEventListener.validate(ValidateEventListener.java:148) at org.hibernate.validator.event.ValidateEventListener.onPreInsert(ValidateEventListener.java:172) at org.hibernate.action.EntityIdentityInsertAction.preInsert(EntityIdentityInsertAction.java:119) at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:42) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:290) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:180) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:108) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:618) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:592) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:596) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:213) at br.com.kinomaxx.kinosystem.dao.EntityManagerWrapperBean.persist(EntityManagerWrapperBean.java:52) 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.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:45) at org.mycontainer.jpa.PersistenceContextInterceptor.intercept(PersistenceContextInterceptor.java:53) at org.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:35) at org.mycontainer.kernel.interceptors.NamingInjectInterceptor.intercept(NamingInjectInterceptor.java:48) at org.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:35) at org.mycontainer.kernel.interceptors.NamingInjectInterceptor.intercept(NamingInjectInterceptor.java:48) at org.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:35) at org.mycontainer.ejb.interceptor.EJBContextInterceptor.intercept(EJBContextInterceptor.java:55) at org.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:35) at org.mycontainer.ejb.transaction.RequiredTransactionHandler.intercept(RequiredTransactionHandler.java:38) at org.mycontainer.ejb.interceptor.TransactionInterceptor.intercept(TransactionInterceptor.java:52) at org.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:35) at org.mycontainer.ejb.interceptor.EJBExceptionInterceptor.intercept(EJBExceptionInterceptor.java:27) at org.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:35) at org.mycontainer.kernel.reflect.proxy.ProxyEngine.invoke(ProxyEngine.java:77) at $Proxy33.persist(Unknown Source) at br.com.kinomaxx.kinosystem.CustomerTest.test(CustomerTest.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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) javax.ejb.EJBException: nested exception is: org.hibernate.validator.InvalidStateException: validation failed for: br.com.kinomaxx.kinosystem.Customer at org.mycontainer.ejb.interceptor.EJBExceptionInterceptor.intercept(EJBExceptionInterceptor.java:31) at org.mycontainer.kernel.reflect.proxy.ProxyChainImpl.proceed(ProxyChainImpl.java:35) at org.mycontainer.kernel.reflect.proxy.ProxyEngine.invoke(ProxyEngine.java:77) at $Proxy33.persist(Unknown Source) at br.com.kinomaxx.kinosystem.CustomerTest.test(CustomerTest.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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-60) Need Property names along with validation messages (as an option)

by Priya M (JIRA)

Need Property names along with validation messages (as an option) ----------------------------------------------------------------- Key: HV-60 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-60 Project: Hibernate Validator Issue Type: New Feature Reporter: Priya M Forum Tracking. htthttp://www.seamframework.org/Community/ValidationMessagesWithActualPro... Currently, the validation messages don't point to the property name(s) making it too generic and hard to understand. For example, let's say I have 10 properties on the page and there were 3 validations thrown by Hibernate Validator. I get the following messages . value is required . value is required . length should be 20 The above messages is only useful for simple forms where each field is wrapped by an error tag. While working with complex UI (datatables with large rows) and Application code that works with collections, the above messages are redundant if not attached with the corresponding property name. Ideally, it would be useful to have something like this . foo value is required . bar value is required . foobar length should be 20 This could be provided as an optional hibernate attribute in the hibernate properties hibernate.validator.include_property_names=true The only workaround that seems now, is to override each and every validation message in all the entity objects to spit out the property name with validation maessages. (lame!) -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-49) Czech translation

by Petr Ferschmann (JIRA)

Czech translation ----------------- Key: HV-49 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-49 Project: Hibernate Validator Issue Type: Patch Affects Versions: 3.0.0.ga Reporter: Petr Ferschmann Attachments: DefaultValidatorMessages_cs.properties Here is czech translation of hibernate validator. It is against 3.0.0.GA. -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-73) hibernate-validator 3.1.0GA inclusion in maven central repository

by Ari Miller (JIRA)

hibernate-validator 3.1.0GA inclusion in maven central repository ----------------------------------------------------------------- Key: HV-73 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-73 Project: Hibernate Validator Issue Type: Task Affects Versions: 3.1.0.GA Reporter: Ari Miller Priority: Minor Note that hibernate-validator 3.1.0GA is present in: http://repository.jboss.com/maven2/org/hibernate/hibernate-validator/ but not in http://repo2.maven.org/maven2/org/hibernate/hibernate-validator/ Other hibernate project releases have been moved to the central maven repository. The incompatibility problem between validator and core I'm experiencing is described in http://forum.hibernate.org/viewtopic.php?t=992491 -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-44) Make Hibernate Validator multi-lingual

by Olle Hallin (JIRA)

Make Hibernate Validator multi-lingual -------------------------------------- Key: HV-44 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-44 Project: Hibernate Validator Issue Type: Improvement Affects Versions: 3.0.0.ga Reporter: Olle Hallin Hibernate Validator 3.0.0 is unfortunately useless in a multi-lingual web app, since it uses Locale.getDefault() for locating the validation message bundle. Each and every HTTP request can have a different locale, in it's own thread. Please add something in line with Spring's LocaleContextHolder (a ThreadLocal), which can be set early in the request handling chain. If not set, it could fall back to the platform's Locale.getDefault(). -- 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

17 years, 3 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HV-52) unified unit testing pattern for standalone validators

by Sanne Grinovero (JIRA)

unified unit testing pattern for standalone validators ------------------------------------------------------ Key: HV-52 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-52 Project: Hibernate Validator Issue Type: Patch Affects Versions: 3.0.0.ga Reporter: Sanne Grinovero Priority: Minor Attachments: validator-testing-cleanup.patch Hi, I've seen some bugs in the validator I would like to help solving, but the main issue I've seen is that to write unittests the code is quite verbose; the consequence is that mission-critical code is well tested but most trivial code is untested. It looks like to me that most JIRA issues here are relevant to this "untested trivial" code... I would appreciate if you could apply this patch that greatly simplifies writing of unit tests for standalone validators, as I would like to send some more patches using this code to develop test-first. This affects only the "test" source, diffed from 3.0.0.GA, and includes some new testing of @NotEmpty and @Digits; I would add much more tests if you're not against it. With "standalone validators" i mean that this is not useful for graph/integration testing, just each validator on some property. Sanne -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-42) Reference Documentation: broken example

by Robert Spielmann (JIRA)

Reference Documentation: broken example --------------------------------------- Key: HV-42 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-42 Project: Hibernate Validator Issue Type: Bug Components: documentation Reporter: Robert Spielmann Priority: Trivial The Hibernate Validator Reference Guide (Hibernate Validator 3.0.0.GA) contains examples for writing custom annotations and validators, section 1.4 "writing your own constraints". There, it says that the class CapitalizedValidator implements Validator<Capitalized> and PropertyConstraint. The example class, however, does not implement the "apply" method. Thus, the example class does not compile. Additionally, the class "Capitalize" (containing constants like FIRST) is not defined anywhere. This leaves the example incomplete and thus - unless you quickly implement this class - unsuable for practical experiments. -- 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

17 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HV-25) Generated DDL ignores Validator annotations on component fields and superclass fields

by Ben Anderson (JIRA)

Generated DDL ignores Validator annotations on component fields and superclass fields ------------------------------------------------------------------------------------- Key: HV-25 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-25 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 3.0.0.ga Environment: Windows XP, Hibernate 3.2.4.sp1, Hibernate Annotations 3.3.0.ga, Postgres, HSQL Reporter: Ben Anderson Attachments: model.zip The DDL generated for entities containing components or superclass properties does not reflect any Validator length restrictions or not-null constraints that have been defined on those component or superclass properties i.e. a component with a property containing the @Length(max = 50) and @NotNull annotation is generated as varchar(255) with nulls permitted (at the database level). I've posted a more detailed example to the forum at http://forum.hibernate.org/viewtopic.php?t=975612 Another example can be found at http://www.ibm.com/developerworks/web/library/j-hibval.html - the SQL generated when this schema is exported is: create table cc (id integer not null, fname varchar(255), mi varchar(255), lname varchar(255), addr1 varchar(255), addr2 varchar(255), city varchar(255), zipcode varchar(255), state_id varchar(255), cvv2 varchar(6) not null, expiration_date timestamp not null, type_id integer not null, num varchar(30) not null, customer_id integer not null, primary key (id)); create table customer (id integer not null, dob timestamp, phone varchar(255), fax varchar(255), email varchar(255), fname varchar(255), mi varchar(255), lname varchar(255), addr1 varchar(255), addr2 varchar(255), city varchar(255), zipcode varchar(255), state_id varchar(255), primary key (id)); The SQL should be: create table cc (id integer not null, fname varchar(30) not null, mi varchar(1), lname varchar(30) not null, addr1 varchar(50) not null, addr2 varchar(50), city varchar(50) not null, zipcode varchar(15) not null, state_id varchar(2) not null, cvv2 varchar(6) not null, expiration_date timestamp not null, type_id integer not null, num varchar(30) not null, customer_id integer not null, primary key (id)); create table customer (id integer not null, dob timestamp, phone varchar(13), fax varchar(13), email varchar(40), fname varchar(30) not null, mi varchar(1), lname varchar(30) not null, addr1 varchar(50) not null, addr2 varchar(50) not null, city varchar(50) not null, zipcode varchar(15) not null, state_id varchar(2) not null, primary key (id)); I've attached the relevant classes from this example. -- 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

17 years, 3 months

6
7
0 / 0

[Hibernate-JIRA] Created: (HV-31) Support user defined Locale for the ResourceBundle

by Emmanuel Bernard (JIRA)

Support user defined Locale for the ResourceBundle -------------------------------------------------- Key: HV-31 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-31 Project: Hibernate Validator Issue Type: New Feature Components: engine 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-27) Accessing Public Methods In A Default Access Superclass

by Ilya Kharmatsky (JIRA)

Accessing Public Methods In A Default Access Superclass ------------------------------------------------------- Key: HV-27 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-27 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 3.0.0.ga Environment: pure jdk 5.0 Reporter: Ilya Kharmatsky Attachments: bugs.zip I'm not sure that this project is right place for this bug (probably better place is hibernate.annotations?), but since I've found the bug through hibernate.validator - I'm posting it here. In general, the problem is well-known and already resolved, for example here: http://jakarta.apache.org/commons/beanutils/apidocs/org/apache/commons/be... When I'm using the hibernate.validator on the application level (through test cases) I'm getting following error: java.lang.IllegalStateException: Could not get property value at org.hibernate.validator.ClassValidator.getMemberValue(ClassValidator.java:537) at org.hibernate.validator.ClassValidator.getInvalidValues(ClassValidator.java:383) at org.hibernate.validator.ClassValidator.getInvalidValues(ClassValidator.java:351) at bugs.HibenrateValidatorPackageAccessBug.testMyPojo2(HibenrateValidatorPackageAccessBug.java:47) Please see attached test case. -- 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

17 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HV-22) Provide contextual validation

by Emmanuel Bernard (JIRA)

Provide contextual validation ----------------------------- Key: HV-22 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-22 Project: Hibernate Validator Issue Type: New Feature Components: engine Reporter: Emmanuel Bernard The basic idea is to have a special parameter in annotations named context(s) @NotNull(message="doh", context = {"screen1Input", "screen2Input", "default"}) "default" being a special context, the one applied every time (including in the DDL) no context or an empty context is equivalent to "default" The regular API are running against "default" Override the regular APIs with getInvalidValues(..., String context); Not entirely sure the idea will float, but it sounds like a non invasive way to do it. PS this might require to create @[Name]s annotations ie @NotNulls({@NotNull(message="m1", context="earlyStage"), @NotNull(message="m2")}) -- 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

17 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-75) Error message localization fails with polymorphism

by Samppa Saarela (JIRA)

Error message localization fails with polymorphism -------------------------------------------------- Key: HV-75 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-75 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 3.1.0.GA, 3.1.0.CR2, 3.1.0.CR1, 3.0.0.ga Reporter: Samppa Saarela Error message localization fails with polymorphism. ClassValidator doesn't pass messageBundle to the nested validator: 1 private ClassValidator getClassValidator(Object value) { 2 Class clazz = value.getClass(); 3 ClassValidator validator = childClassValidators.get( reflectionManager.toXClass( clazz ) ); 4 if ( validator == null ) { //handles polymorphism 5 validator = new ClassValidator( clazz ); 6 } 7 return validator; 8 } This can be solved easily(?) by passing on the messageBundle on line 5: validator = new ClassValidator( clazz, messageBundle ); -- 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

17 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-32) Provide a way to turn on recursive validation by default without @Valid needed

by Jacques Morel (JIRA)

Provide a way to turn on recursive validation by default without @Valid needed ------------------------------------------------------------------------------ Key: HV-32 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-32 Project: Hibernate Validator Issue Type: Improvement Reporter: Jacques Morel Hibernate validation annotation is a great way to specify declaratively and cohesively the validation rules of a domain model. Unfortunately it can also become very verbose. As any good frameworks, hibernate validator should provide ways to set sensible defaults. In the case of recursive validation, we should have a way to turn it one at the class level or at the ClassValidator level. -- 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

17 years, 3 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HV-28) "connection already null in cleanup" when using validators

by David J. M. Karlsen (JIRA)

"connection already null in cleanup" when using validators ---------------------------------------------------------- Key: HV-28 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-28 Project: Hibernate Validator Issue Type: Bug Environment: hibernate annotations 3.3.0ga hibernate validator 3.0.0ga hibernate 3.2.4.sp1 hibernate-commons-annotations 3.3.0.ga Reporter: David J. M. Karlsen Priority: Critical 2007-06-27 21:18:39,133 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.impl.SessionImpl - opened session at timestamp: 11829719154 (SessionImpl.java:220) 2007-06-27 21:18:39,159 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.DefaultSaveOrUpdateEventListener - saving transient instance (DefaultSaveOrUpdateEventListener.java:158) 2007-06-27 21:18:39,162 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractSaveEventListener - generated identifier: e2632934-a800-4a91-a9ff-ce8e1f95a03d, using strategy: org.hibernate.id.Assigned (AbstractSaveE ventListener.java:112) 2007-06-27 21:18:39,168 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractSaveEventListener - saving [mypackage.server.types.Fee#e2632934-a800-4a91-a9ff-ce8e1f95a03d] (AbstractSaveEventListener.java: 153) 2007-06-27 21:18:39,228 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - flushing session (AbstractFlushingEventListener.java:58) 2007-06-27 21:18:39,232 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - processing flush-time cascades (AbstractFlushingEventListener.java:111) 2007-06-27 21:18:39,237 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - dirty checking collections (AbstractFlushingEventListener.java:154) 2007-06-27 21:18:39,238 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - Flushing entities and processing referenced collections (AbstractFlushingEventListener.java:171) 2007-06-27 21:18:39,249 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - Processing unreferenced collections (AbstractFlushingEventListener.java:210) 2007-06-27 21:18:39,251 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - Scheduling collection removes/(re)creates/updates (AbstractFlushingEventListener.java:224) 2007-06-27 21:18:39,252 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - Flushed: 1 insertions, 0 updates, 0 deletions to 1 objects (AbstractFlushingEventListener.java:85) 2007-06-27 21:18:39,254 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections (AbstractFlushingEventListener.java:91) 2007-06-27 21:18:39,260 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.pretty.Printer - listing entities: (Printer.java:83) 2007-06-27 21:18:39,262 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.pretty.Printer - mypackage.types.Fee{<values anonymized>} (Printer.java:90) 2007-06-27 21:18:39,264 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - executing flush (AbstractFlushingEventListener.java:290) 2007-06-27 21:18:39,265 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.jdbc.ConnectionManager - registering flush begin (ConnectionManager.java:469) 2007-06-27 21:18:39,276 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.jdbc.ConnectionManager - registering flush end (ConnectionManager.java:478) 2007-06-27 21:18:39,278 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.impl.SessionImpl - after transaction completion (SessionImpl.java:422) 2007-06-27 21:18:39,280 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.impl.SessionImpl - closing session (SessionImpl.java:273) 2007-06-27 21:18:39,281 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.jdbc.ConnectionManager - connection already null in cleanup : no action (ConnectionManager.java:375) 2007-06-27 21:18:39,298 [WorkManager.DefaultWorkManager : 0] ERROR Could not insert Fee org.hibernate.validator.InvalidStateException: validation failed for: mypackage.server.types.Fee at org.hibernate.validator.event.ValidateEventListener.validate(ValidateEventListener.java:148) at org.hibernate.validator.event.ValidateEventListener.onPreInsert(ValidateEventListener.java:172) at org.hibernate.action.EntityInsertAction.preInsert(EntityInsertAction.java:156) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:49) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141) This only seems to happen when I'm running inside an appserver (WebSphere 6.1) with pooled connections - in my unit-tests using a org.springframework.jdbc.datasource.DriverManagerDataSource (eg. non-pooled) it works OK - and only if adding validating annotations (@NotEmpty) -- 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

17 years, 3 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HV-37) Validating a lazy collection of composite-elements causes flush problem

by Ian Long (JIRA)

Validating a lazy collection of composite-elements causes flush problem ------------------------------------------------------------------------ Key: HV-37 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-37 Project: Hibernate Validator Issue Type: Bug Affects Versions: 3.0.0.ga Environment: Hibernate 3.2.4ga Hibernate Annotations 3.3.0.ga mysql 5.0.27 Reporter: Ian Long Using the event listeners(pre-update,pre-insert) in hibernate, a problem occurs when validating a lazy collection of composite-elements. I was using the @Size validator, but I'm sure others will cause the same problem. For example: <set name="activatedModules" lazy="true" table="location_module_activation"> <key column="location_id" /> <composite-element class="com.opterus.opscenter.model.module.ActivatedModule" > <property name="activationDate" column="activate_date" not-null="true" /> <many-to-one name="module" class="com.opterus.opscenter.model.module.Module" column="module_id" not-null="true" unique="false" /> </composite-element> </set> will cause an exception during flush: 01:53:55,587 ERROR [http-8080-Processor23] AssertionFailure:22 - an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) org.hibernate.AssertionFailure: collection [com.opterus.opscenter.model.common.Brand.regions] was not processed by flush() at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205) at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28) Since it tries to access the proxied collection. A collection of entity objects does not cause this problem. I guess the composite-element is handled differently than regular collections? Filed at the request of emmanuel, from the following thread: http://forum.hibernate.org/viewtopic.php?p=2361829#2361829 -- 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

17 years, 3 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3640) Some standard SQL functions are not implemented in Sybase

by Juraci Paixao Krohling (JIRA)

Some standard SQL functions are not implemented in Sybase --------------------------------------------------------- Key: HHH-3640 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3640 Project: Hibernate Core Issue Type: Improvement Components: testsuite Environment: Sybase ASE 15.0.2 Reporter: Juraci Paixao Krohling Assignee: Juraci Paixao Krohling Attachments: ASTParserLoadingTest.java.diff Some standard SQL functions are not implemented in Sybase, like "mod" * , bit_length, trim. Thus, the tests which uses these functions needs to be evicted. ASTParserLoadingTest, contains "trim(trailing '_' column) ... " , mod(x,y) and bit_length -- 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

17 years, 3 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HHH-3599) Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result table"

by Dirk Lachowski (JIRA)

Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result table" ---------------------------------------------------------------------------------------- Key: HHH-3599 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3599 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Environment: MaxDB 7.6.05.09, Linux, JDBC Reporter: Dirk Lachowski We have a quite simple domain object: @Entity @Table(name = "cc_user_assignment") @org.hibernate.annotations.Proxy(lazy = true) public class CostCenterUserAssignment { private Long id; private Contact contact; private Set<CostCenter> costCenter = new HashSet<CostCenter>(); private CostCenter defaultCostCenter; @ManyToMany @JoinTable(name = "j_cc_user2user", joinColumns = { @JoinColumn(name = "user_assignment_id") }, inverseJoinColumns = @JoinColumn(name = "cost_center_id")) public Set<CostCenter> getCostCenter() { return costCenter; } public void removeCostCenter(CostCenter ccRemove) { costCenter.remove(ccRemove); } } Most of the time the call to "removeCostCenter()" succeeds, but now we have a non-reproducible situation where the call to costCenter.remove(ccRemove) fails. It seems to be data-dependend as it occurs in one of our productive systems. There it is reproducible for one set of data. First we thought it is dependent on the data-size but we are not able to reproduce it by simply creating another dataset of the same size. The select created for the proxy-materializing is: select costcenter0_.user_assignment_id as user1_10_, costcenter0_.cost_center_id as cost2_10_, costcenter1_.id as id169_0_, costcenter1_.accountNumber as accountN2_169_0_, costcenter1_.balance as balance169_0_, costcenter1_.balance_currency as balance4_169_0_, costcenter1_.budget as budget169_0_, costcenter1_.budget_currency as budget6_169_0_, costcenter1_.budgetExcessAllowed as budgetEx7_169_0_, costcenter1_.bdg_extra as bdg8_169_0_, costcenter1_.bdg_extra_currency as bdg9_169_0_, costcenter1_.budgetPeriod as budgetP10_169_0_, costcenter1_.customer_id as customer13_169_0_, costcenter1_.manager_id as manager14_169_0_, costcenter1_.name as name169_0_, costcenter1_.transferBudget as transfe12_169_0_, customer2_.id as id167_1_, customer2_.accountId as accountId167_1_, customer2_.addr_id as addr16_167_1_, customer2_.attribute01 as attribute3_167_1_, customer2_.attribute02 as attribute4_167_1_, customer2_.attribute03 as attribute5_167_1_, customer2_.attribute04 as attribute6_167_1_, customer2_.attribute05 as attribute7_167_1_, customer2_.attribute06 as attribute8_167_1_, customer2_.attribute07 as attribute9_167_1_, customer2_.attribute08 as attribute10_167_1_, customer2_.attribute09 as attribute11_167_1_, customer2_.attribute10 as attribute12_167_1_, customer2_.delivery_lock_id as delivery17_167_1_, customer2_.externalAccountId1 as externa13_167_1_, customer2_.externalAccountId2 as externa14_167_1_, customer2_.owner_id as owner18_167_1_, customer2_.pricelist_id as pricelist19_167_1_, customer2_.pricingSchemaName as pricing15_167_1_, address3_.id as id165_2_, address3_.city as city165_2_, address3_.country_id as country16_165_2_, address3_.fax as fax165_2_, address3_.fon as fon165_2_, address3_.houseNumber as houseNum5_165_2_, address3_.mail as mail165_2_, address3_.name1 as name7_165_2_, address3_.name2 as name8_165_2_, address3_.name3 as name9_165_2_, address3_.name4 as name10_165_2_, address3_.postbox as postbox165_2_, address3_.postcode as postcode165_2_, address3_.postcodeCompany as postcod13_165_2_, address3_.postcodePostbox as postcod14_165_2_, address3_.street as street165_2_, address3_.title_id as title17_165_2_, country4_.id as id159_3_, country4_.isoCode as isoCode159_3_, country4_.name as name159_3_, title5_.id as id163_4_, title5_.isOrganization as isOrgani2_163_4_, title5_.name as name163_4_, deliverylo6_.id as id191_5_, deliverylo6_.autoDeliveryLock as autoDeli2_191_5_, deliverylo6_.description as descript3_191_5_, deliverylo6_.messageLock as messageL4_191_5_, deliverylo6_.name as name191_5_, deliverylo6_.orderLock as orderLock191_5_, deliverylo6_.reservationLock as reservat7_191_5_, pricelistt7_.id as id175_6_, pricelistt7_.description as descript2_175_6_, pricelistt7_.name as name175_6_, contact8_.id as id166_7_, contact8_.customer_id as customer12_166_7_, contact8_.firstName as firstName166_7_, contact8_.ignoreAssortment as ignoreAs3_166_7_, contact8_.lastName as lastName166_7_, contact8_.officeFax as officeFax166_7_, contact8_.officeMail as officeMail166_7_, contact8_.officeMobile as officeMo7_166_7_, contact8_.officePhone as officePh8_166_7_, contact8_.role as role166_7_, contact8_.title_id as title13_166_7_, contact8_.webPassword as webPass10_166_7_, contact8_.webUserName as webUser11_166_7_, customer9_.id as id167_8_, customer9_.accountId as accountId167_8_, customer9_.addr_id as addr16_167_8_, customer9_.attribute01 as attribute3_167_8_, customer9_.attribute02 as attribute4_167_8_, customer9_.attribute03 as attribute5_167_8_, customer9_.attribute04 as attribute6_167_8_, customer9_.attribute05 as attribute7_167_8_, customer9_.attribute06 as attribute8_167_8_, customer9_.attribute07 as attribute9_167_8_, customer9_.attribute08 as attribute10_167_8_, customer9_.attribute09 as attribute11_167_8_, customer9_.attribute10 as attribute12_167_8_, customer9_.delivery_lock_id as delivery17_167_8_, customer9_.externalAccountId1 as externa13_167_8_, customer9_.externalAccountId2 as externa14_167_8_, customer9_.owner_id as owner18_167_8_, customer9_.pricelist_id as pricelist19_167_8_, customer9_.pricingSchemaName as pricing15_167_8_, title10_.id as id163_9_, title10_.isOrganization as isOrgani2_163_9_, title10_.name as name163_9_ from j_cc_user2user costcenter0_, cost_center costcenter1_, KNA1 customer2_, ADDR address3_, C005 country4_, CSAD3 title5_, delivery_lock deliverylo6_, sd_pr_prltype pricelistt7_, KNVK contact8_, KNA1 customer9_, CSAD3 title10_ where costcenter0_.cost_center_id=costcenter1_.id(+) and costcenter1_.customer_id=customer2_.id(+) and customer2_.addr_id=address3_.id(+) and address3_.country_id=country4_.id(+) and address3_.title_id=title5_.id(+) and customer2_.delivery_lock_id=deliverylo6_.id(+) and customer2_.pricelist_id=pricelistt7_.id(+) and costcenter1_.manager_id=contact8_.id(+) and contact8_.customer_id=customer9_.id(+) and contact8_.title_id=title10_.id(+) and costcenter0_.user_assignment_id=? The same query can be successfully submitted using database studio. Maybe it's related to this: http://osdir.com/ml/db.maxdb/2004-10/msg00199.html A full stack trace is available here: http://jira.lacho.net/jira/browse/ES-579 -- 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

17 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3650) TableGenerator doesn't marks the "primary key" as not null, causing errors in some RDBMS's which expects the PK to be not-null

by Juraci Paixao Krohling (JIRA)

TableGenerator doesn't marks the "primary key" as not null, causing errors in some RDBMS's which expects the PK to be not-null ------------------------------------------------------------------------------------------------------------------------------ Key: HHH-3650 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3650 Project: Hibernate Core Issue Type: Patch Components: core Environment: DB2v82 and Branch_3_3 and trunk Reporter: Juraci Paixao Krohling Assignee: Juraci Paixao Krohling Attachments: TableGenerator.java.diff Some RDBMS's requires that the primary key columns be not-null. This causes some tests which relies on the org.hibernate.id.enhanced.TableGenerator to fail on error. The attached patch adds the string "not null" to the table creation statement. -- 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

17 years, 3 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3275) Allow pluggable tuplizers for composite elements

by Chris Bredesen (JIRA)

Allow pluggable tuplizers for composite elements ------------------------------------------------ Key: HHH-3275 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3275 Project: Hibernate3 Issue Type: Improvement Components: metamodel Reporter: Chris Bredesen Priority: Minor By looking at the hibernate-mapping DTD, it does not seem possible to define a tuplizer for a composite-element. However, composite elements have component semantics, so if Hibernate allows pluggable tuplizer for components, one would expect the same thing about composite elements. -- 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

17 years, 3 months

4
14
0 / 0

[Hibernate-JIRA] Created: (HHH-3607) Adding primary key to TableGenerator causes problem on DB2

by Neale Swinnerton (JIRA)

Adding primary key to TableGenerator causes problem on DB2 ---------------------------------------------------------- Key: HHH-3607 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3607 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: hibernate 3.3.1.GA, Database server = DB2/LINUXX8664 9.1.5 Reporter: Neale Swinnerton Attachments: not-null.patch The change made in HHH-2686 to add a primary key to the generator table doesn't work on DB2, because there isn't a not null clause on the primary key column. attached patch adds the not null clause. I believe this should be portable across all DBs? -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3438) Could not check JTA transaction; nested exception is java.lang.StackOverflowError

by Jara Cesnek (JIRA)

Could not check JTA transaction; nested exception is java.lang.StackOverflowError --------------------------------------------------------------------------------- Key: HHH-3438 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3438 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.GA Reporter: Jara Cesnek This code cause infinite loop. Moreover still dont work with JOTM. HHH-3358 protected UserTransaction *getUserTransaction*() { log.trace( "Attempting to locate UserTransaction via JNDI [{}]", getUserTransactionName() ); try { UserTransaction ut = ( UserTransaction ) getInitialContext().lookup( getUserTransactionName() ); if ( ut == null ) { throw new TransactionException( "Naming service lookup for UserTransaction returned null [" + getUserTransactionName() +"]" ); } log.trace( "Obtained UserTransaction" ); return ut; } catch ( NamingException ne ) { throw new TransactionException( "Could not find UserTransaction in JNDI [" + *getUserTransaction()* + "]", ne ); } } -- 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

17 years, 3 months

4
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-69) The default MessageResolver now handles Locale

by Emmanuel Bernard (JIRA)

The default MessageResolver now handles Locale ---------------------------------------------- Key: BVAL-69 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-69 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Fix For: 1.0 public draft This is not the case of the actual implementation. -- 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

17 years, 3 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2921) Polymorphic query breaks if entity proxy already exists in session

by Johan Hoogenboezem (JIRA)

Polymorphic query breaks if entity proxy already exists in session ------------------------------------------------------------------ Key: HHH-2921 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2921 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: 3.2.5, PostgreSQL 8.1.2, jdk1.5.0_08, Windows XP Reporter: Johan Hoogenboezem I posted to the user forum about this on Oct 26 (http://forum.hibernate.org/viewtopic.php?t=980752). I've had no reply. This is a serious hassle for me, so I submit it as a bug. -- 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

17 years, 3 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HBX-1091) Cannot open with Hibernate 3.0 XML Editor in Eclipse

by sbgoh (JIRA)

Cannot open with Hibernate 3.0 XML Editor in Eclipse ---------------------------------------------------- Key: HBX-1091 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1091 Project: Hibernate Tools Issue Type: Task Components: eclipse Affects Versions: 3.2.cr1 Environment: Hibernate version: 3.0 Database platform: Oracle 9i Reporter: sbgoh Hi, I have include the hibernate tools plugins in Eclipse 3.3.2. However, I can't open the map file (.hbm.xml) with Hibernate 3.0 XML Editor. Is there any other settings required to activate this editor? Thanks in advance. -- 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

17 years, 3 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HBX-770) Consider integration/union between Eclipse Dali and Hibernate Tools

by Diego Pires Plentz (JIRA)

Consider integration/union between Eclipse Dali and Hibernate Tools ------------------------------------------------------------------- Key: HBX-770 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-770 Project: Hibernate Tools Type: Improvement Reporter: Diego Pires Plentz What about? Consider integration/union between Eclipse Dali and Hibernate Tools. An official Hibernate project, fully integrated with an oficial Eclipse project. http://www.eclipse.org/dali/ -- 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

17 years, 3 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2524) Criteria query with collection of values (Set<java.lang.String>)

by marco molinari (JIRA)

Criteria query with collection of values (Set<java.lang.String>) ---------------------------------------------------------------- Key: HHH-2524 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2524 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.2 Environment: Java VM : 1.5.0_07 DBMS : HSQLDB Hibernate: hibernate-3.2.2.ga Reporter: marco molinari Hi to all, I have a problem with Criteria query on collection of values. Below I wrote a piece of java code and a piece of Person.hbm.xml. I want to search all persons with the email addresses containing character '@'. I obtain an empty list of Person and the SQL created by Criteria seems not correct ( more or less ... WHERE lower(PERSON_ID) ? ). I search information inside Hibernate site and Hibernate book but I didn't found the solution. public class Person { private Long id; private Set<String> emailAddresses = new HashSet(); public Set<String> getEmailAddresses() { return emailAddresses; } public void setEmailAddresses(Set<String> emailAddresses) { this.emailAddresses = emailAddresses; } } public static void main(String[] args) { List<Person> list = session.createCriteria(Person.class) .add( Restrictions.ilike( "emailAddresses", "@", MatchMode.ANYWHERE ) ) .list(); } Piece of Person.hbm.xml: <set name="emailAddresses" table="'PERSON_EMAIL_ADDR'" inverse="true"> <key column="'PERSON_ID'"/> <element column="'EMAIL_ADDR'" type="java.lang.String" not-null="true"/> </set> -- 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

17 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2875) upgrade to cglib 2.2 (which uses the new asm 2 apis)

by Steve Ebersole (JIRA)

upgrade to cglib 2.2 (which uses the new asm 2 apis) ---------------------------------------------------- Key: HHH-2875 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2875 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Gail Badner Priority: Blocker Fix For: 3.2.6, 3.3 upgrade to cglib 2.2 (which uses the new asm 2 apis) -- 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

17 years, 3 months

5
13
0 / 0

[Hibernate-JIRA] Created: (BVAL-28) Types should be determined at runtime

by Emmanuel Bernard (JIRA)

Types should be determined at runtime ------------------------------------- Key: BVAL-28 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-28 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard More specifically Person is a superclass of Customer Customer cust = ...; Validator<Person> personValidator = factory.getValidator(Person.class); personValidator.validate(cust); should return invalid constraints declared on Customer. -- 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

17 years, 3 months

2
4
0 / 0

[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

17 years, 3 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

17 years, 3 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

17 years, 3 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

17 years, 3 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

17 years, 3 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

17 years, 3 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

17 years, 3 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

17 years, 3 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

17 years, 3 months

5
13
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-151) Use IndexWriter.autocommit false if Lucene 2.3 is used

by Emmanuel Bernard (JIRA)

Use IndexWriter.autocommit false if Lucene 2.3 is used ------------------------------------------------------ Key: HSEARCH-151 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-151 Project: Hibernate Search Issue Type: New Feature 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

17 years, 3 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HBX-1014) Could not load JPA Configuration

by Reto Urfer (JIRA)

Could not load JPA Configuration -------------------------------- Key: HBX-1014 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1014 Project: Hibernate Tools Issue Type: Bug Components: consoleconfiguration Affects Versions: 3.2.cr1 Environment: Hibernate 3.2.4, Hibernate Annotations 3.3.0, Hibernate EntityManager 3.3.1, Oracle 10g R2 Reporter: Reto Urfer If the project name contains a <SPACE> character, the following exception occurs when you try to browse the console configuration: org.hibernate.console.HibernateConsoleRuntimeException: Could not load JPA Configuration at org.hibernate.console.ConsoleConfiguration.buildConfiguration(ConsoleConfiguration.java:499) at org.hibernate.console.ConsoleConfiguration.access$0(ConsoleConfiguration.java:484) at org.hibernate.console.ConsoleConfiguration$2.execute(ConsoleConfiguration.java:203) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:65) at org.hibernate.console.ConsoleConfiguration.buildWith(ConsoleConfiguration.java:185) at org.hibernate.console.ConsoleConfiguration.build(ConsoleConfiguration.java:106) at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:38) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:97) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:103) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:196) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: org.hibernate.console.HibernateConsoleRuntimeException: Could not create JPA based Configuration at org.hibernate.console.ConsoleConfiguration.buildJPAConfiguration(ConsoleConfiguration.java:142) at org.hibernate.console.ConsoleConfiguration.buildConfiguration(ConsoleConfiguration.java:496) ... 10 more Caused by: java.lang.reflect.InvocationTargetException 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:597) at org.hibernate.console.ConsoleConfiguration.buildJPAConfiguration(ConsoleConfiguration.java:133) ... 11 more Caused by: javax.persistence.PersistenceException: java.lang.IllegalArgumentException: Unable to visit JAR file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin. Cause: Illegal character in path at index 53: file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:258) ... 16 more Caused by: java.lang.IllegalArgumentException: Unable to visit JAR file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin. Cause: Illegal character in path at index 53: file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin at org.hibernate.ejb.packaging.JarVisitor.getVisitor(JarVisitor.java:112) at org.hibernate.ejb.Ejb3Configuration.getMainJarVisitor(Ejb3Configuration.java:266) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:239) ... 16 more If the project is renamed so it does not contain any <SPACE> characters anymore it works fine. This problem did not occur in Hibernate Tools 3.2 Beta11 -- 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

17 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3665) Easy-to-use method, to check if object has already been loaded

by Markus Merder (JIRA)

Easy-to-use method, to check if object has already been loaded -------------------------------------------------------------- Key: HHH-3665 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3665 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Markus Merder Priority: Trivial Currently there is no easy-to-use-method to check if an entity is in session-cache without loading it. SessionImpl.getEntityUsingInterceptor checks this and could be used. It would be nice, if there was a method like this in SessionImpl: public boolean checkIfInCache(Class entityClass, Serializable id) { return getEntityUsingInterceptor(new EntityKey(id, getFactory().getEntityPersister(entityClass.getName()), getEntityMode())) != 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

17 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3584) Generate SQL when Dynamic Update is true is including version field even when marked as updateable=false

by Dave Stephan (JIRA)

Generate SQL when Dynamic Update is true is including version field even when marked as updateable=false -------------------------------------------------------------------------------------------------------- Key: HHH-3584 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3584 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1, 3.2.4.sp1 Reporter: Dave Stephan If an entity has the annotation: @Enitity(dynamicUpdate=true) And a field annotated as : @Version @Generated(GenerationTime.Always) @Column(updateable=false, insertable=false) The generated update sql will include the annotated field in the properties to be updated. This is incorrect and causes exceptions in certain cases. E.g updating a view where the resulting columns cross multiple tables. When the dynamicUpdate is set to true, the sql string is generated dynamically and initially the field marked as updateable=false is flagged as not to be included. The AbstractEntityPersiter.getPropertiesToUpdate method then checks if there is a versioning field, finds the above annotated column and now flags it to be included, neglecting to check whether this versioning field has also been marked as updateable=false, or whether @Generated(GenerationTime.ALWAYS) is there. (Although the last isn't really necessary as this annotation can't be there without the column being marked as not updateable and not insertable.) -- 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

17 years, 3 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-2855) Error during a entity collection loading - wrong SQL query generation - missing discriminator condition in the "where" clause for a specific subclass

by Peter Fassev (JIRA)

Error during a entity collection loading - wrong SQL query generation - missing discriminator condition in the "where" clause for a specific subclass ----------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2855 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2855 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: Peter Fassev Priority: Critical Attachments: testcase.zip There is a problem, when loading a entity collection (bag), when the collection element is a subclass. The query, witch fetches the elements of the collection, does not use the discriminator value of a subclass and thus loads also other elements form different classes. Please look at the simple test case I have provided. Here is a simple description: Having a base class A with two subclasses AA and AB, the class A has many-to-one connection to another base class B. The class B itself has two different collections (bags), the first contains only AA elements, the second bag BB elements. The classes AA and AB has different integer properties. When I try to load an instance of class B, which is connected to some AA and AB instances, and than try to access the list of all connected AA instances, there is an exception, because Hibernate tries to load all AA and AB instances in one and the same AA collection. The exception is actually thrown, because Hibernate tries to instanciate an AA instance from a AB data! This is the case, because the selection query, which is generated automatically by Hibernate, does not use the discriminator value of the AA subclass to load the collection, and thus selects the AA and AB elements from the database. WORKAROND: Currently, the only workaround i found is to define a "where" parameter in the hibernate-mapping with for each collection with the appropriated subclass discriminator. -- 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

17 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2650) Allow for an entire Session to be readOnly, add Session.setReadOnly() method

by Gunther Schadow (JIRA)

Allow for an entire Session to be readOnly, add Session.setReadOnly() method ---------------------------------------------------------------------------- Key: HHH-2650 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2650 Project: Hibernate3 Issue Type: Sub-task Components: core Environment: Any Reporter: Gunther Schadow There is a need for read-only applications to avoid any snapshoting of objects if that application never intends to make updates. Such readOnly mode would be the mode in which any object gets loaded into the session, whether directly or from lazy collections. The use case is reporting applications which want to make sure that they don't even accidentally make updates AND that want to save the time it takes to create snapshots because they read through a lot of data very quickly. Our own need is that we have a rich client where we hold read only sessions open for browsing and where we spawn off any change transactions into separate Sessions. Even in change transactions we like to have all objects locked from even accidental updates unless they are explicitly unlocked. A Session.setReadOnly() method would be ideal to do this. It does not appear very hard to make that improvement. We would do it ourselves even if we had some idea if (and under which criteria) our modifications would have a chance to make it into future versions of Hibernate? -- 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

17 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (ANN-632) @IndexColumn doesn't set value of index column

by Dan Allen (JIRA)

@IndexColumn doesn't set value of index column ---------------------------------------------- Key: ANN-632 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-632 Project: Hibernate Annotations Issue Type: Bug Components: documentation Affects Versions: 3.3.0.ga Reporter: Dan Allen I'm sure I will get screamed at for this, but the @IndexColumn just doesn't work with @OneToMany. When I say it doesn't work, it means that I am a reasonable person and I have studied the documentation for at least 4 hours and I just cannot figure out how to make it work. So either the documentation needs to be improved, or there is something wrong with Hibernate. I refuse to believe that I am this stupid. Here is my problem in a nutshell. I have a Person and a collection of Jobs. The Jobs should be an indexed list based on the history that the person holds them. @Entity public class Person { @Id @GeneratedValue private long id; @Column private String name; @OneToMany(cascade=ALL, fetch=LAZY, mappedBy = "job") @IndexColumn(base = 1, name = "order") private List<Job> jobs = new ArrayList<Job>(); // getters and setters } @Entity public class Job { @Id @GeneratedValue private long id; @Column private String name; @ManyToOne @JoinColumn(name="person_id") private Person person; @Column private Integer order; // getters and setters } If I do the following, I get NULL for order. Person person = new Person(); person.setName("Chuck") Job job1 = new Job(); job1.setName("sysadmin") job1.setPerson(person); person.getJobs().add(job1); Job job2 = new Job(); jobs2.setName("network admin") job2.setPerson(person); person.getJobs().add(job2); entityManager.persist(person); Assume that the reason I am not assigning an order is more complex than this example. The point is that we want to see the order column populated with the index of the list. Now, if you give me the business about removing mappedBy, to that I will respond that by removing mappedBy, Hibernate tries to work with a person_job table, which I don't want. I want two tables, one for person and one for job. -- 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

17 years, 3 months

8
15
0 / 0

[Hibernate-JIRA] Created: (HHH-2622) CLONE -Fields quetes must be applied in queries to prevent mix reserved words with fields names

by Igor A Tarasov (JIRA)

CLONE -Fields quetes must be applied in queries to prevent mix reserved words with fields names ----------------------------------------------------------------------------------------------- Key: HHH-2622 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2622 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.0 cr1 Environment: MySQL 4.1.16 Hibernate 3.2 cr1 Fedora Core 4 Reporter: Igor A Tarasov Quotes must be appied to fields in queries. The environment log is: org.hibernate.cfg.Environment Hibernate 3.2 cr1 org.hibernate.cfg.SettingsFactory RDBMS: MySQL, version: 4.1.16 org.hibernate.cfg.SettingsFactory JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-3.1.12 org.hibernate.dialect.Dialect Using dialect: org.hibernate.dialect.MySQLDialect I have an entity, named Group: @Entity public class Group { .. } But, 'GROUP' is the reserved word of MySQL query language. Log of hibernate show, that queries is without quotes: org.hibernate.persister.entity.AbstractEntityPersister Static SQL for entity: org.dicr.isp.entity.Group org.hibernate.persister.entity.AbstractEntityPersister Version select: select id from Group where id =? org.hibernate.persister.entity.AbstractEntityPersister Snapshot select: select group_.id, group_.name as name0_, group_.comment as comment0_ from Group group_ where group_.id=? org.hibernate.persister.entity.AbstractEntityPersister Insert 0: insert into Group (name, comment, id) values (?, ?, ?) org.hibernate.persister.entity.AbstractEntityPersister Update 0: update Group set name=?, comment=? where id=? org.hibernate.persister.entity.AbstractEntityPersister Delete 0: delete from Group where id=? org.hibernate.persister.entity.AbstractEntityPersister Identity insert: insert into Group (name, comment) values (?, ?) And this make a critical error in program logic: org.hibernate.tool.hbm2ddl.DatabaseMetadata table not found: Group ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate Unsuccessful: create table Group (id bigint not null auto_increment, name varchar(255) not null unique, comment varchar(255), primary key (id)) ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'Group (id bigint not null auto_increment, name varchar(255) not null unique, com' at line 1 [2006-04-27 23:57:23,895] INFO org.hibernate.tool.hbm2ddl.SchemaUpdate schema update complete The query: "create table Group (id bigint ..." is not correct. Must be: "create table `Group` (`id` bigint ..." -- 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

17 years, 3 months

4
4
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 December 2008