[Hibernate-JIRA] Created: (HV-427) Can't find validator when type is interface type
by David J. M. Karlsen (JIRA)
Can't find validator when type is interface type
------------------------------------------------
Key: HV-427
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-427
Project: Hibernate Validator
Issue Type: Bug
Components: annotation-processor
Affects Versions: 4.2.0.Beta1
Environment: 4.2.0.beta1
Reporter: David J. M. Karlsen
I have a interface TypeA and and implementation of it ConcreteTypeA implements TypeA.
I have created a JSR-303 constraint both for ConcreteTypeA as well as TypeA - and pointed my constraint to them with @Constraint( validatedBy= ) - but still Hibernate does not find the validator for it:
javax.validation.UnexpectedTypeException: No validator could be found for type: com.edb.payment.pays.core.model.account.NorwegianAccountNumber
at org.hibernate.validator.engine.ConstraintTree.verifyResolveWasUnique(ConstraintTree.java:383)
at org.hibernate.validator.engine.ConstraintTree.findMatchingValidatorClass(ConstraintTree.java:364)
at org.hibernate.validator.engine.ConstraintTree.getInitializedValidator(ConstraintTree.java:313)
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:144)
at org.hibernate.validator.engine.ConstraintTree.validateComposingConstraints(ConstraintTree.java:233)
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:128)
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:117)
at org.hibernate.validator.metadata.MetaConstraint.validateConstraint(MetaConstraint.java:84)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:408)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForRedefinedDefaultGroup(ValidatorImpl.java:341)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:325)
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:281)
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:129)
at com.edb.payment.pays.core.util.validation.constraints.NorwegianAccountNumberValidatorTest.isValid(NorwegianAccountNumberValidatorTest.java:34)
at com.edb.payment.pays.core.util.validation.constraints.NorwegianAccountNumberValidatorTest.assertValid(NorwegianAccountNumberValidatorTest.java:44)
at com.edb.payment.pays.core.util.validation.constraints.NorwegianAccountNumberValidatorTest.testAValidAccountNumberWhichHasControlSumZero(NorwegianAccountNumberValidatorTest.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
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.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
The same implementation works with Apache Bval: http://incubator.apache.org/bval/cwiki/downloads.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[Hibernate-JIRA] Created: (HHH-5899) NPE regression caused by HHH-5824
by Scott Marlow (JIRA)
NPE regression caused by HHH-5824
---------------------------------
Key: HHH-5899
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5899
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Scott Marlow
Fix For: 3.6.2
In the AS testsuite, we noticed a new testsuite failure that appears to be caused by a null value being passed to a ConcurrentHashMap in org.hibernate.impl.SessionFactoryImpl.allCacheRegions. Null values are okay with HashMap but not ConcurrentHashMap.
More details are at https://issues.jboss.org/browse/JBAS-8832
Exception call stack:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:402)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1842)
at org.jboss.hibernate.jmx.Hibernate.buildSessionFactory(Hibernate.java:320)
at org.jboss.hibernate.jmx.Hibernate.start(Hibernate.java:274)
at org.jboss.test.hibernate.test.HibernateConfigurationUnitTestCase.testLegacyPropertyNames(HibernateConfigurationUnitTestCase.java:258)
--
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, 10 months
[Hibernate-JIRA] Updated: (HHH-1268) Unidirection OneToMany causes duplicate key entry violation when removing from list
by Christian Mouttet (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268?page=c... ]
Christian Mouttet updated HHH-1268:
-----------------------------------
Attachment: possible_solution.patch
I checked out {{3.6.0.Final}} and it looks like the attached fix works. There aren't any test case failures/errors.
-chris
> Unidirection OneToMany causes duplicate key entry violation when removing from list
> -----------------------------------------------------------------------------------
>
> Key: HHH-1268
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.1, 3.5.6, 3.6.0
> Environment: 3.1 final
> MySql 4.1.14 using MYISAM tables
> Reporter: Rex Madden
> Assignee: Gail Badner
> Fix For: 3.2.x, 3.3.x
>
> Attachments: possible_solution.patch, src.zip
>
>
> Simple OneToMany parent/child relationship using the default table structure (2 tables and a join table)
> Add 3 children to the parent. Flush. Remove the first child. Flush throws error:
> Exception in thread "main" org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:143)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
> at UnidirectionalOneToManyRemoveFromListBug.main(UnidirectionalOneToManyRemoveFromListBug.java:27)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
> Caused by: java.sql.BatchUpdateException: Duplicate key or integrity constraint violation, message from server: "Duplicate entry '5' for key 2"
> at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1461)
> at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
> at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195)
> ... 11 more
> The problem is that there is a unique key on the relationship table that gets violated. The session removes the last row in the relationship table, then attempts to rewrite the child_id's. It fails since there is a uniqueness constraint on that column.
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2692) Insert Into Select command doesn't allow named parameter as select output (insert input)
by John Aylward (JIRA)
Insert Into Select command doesn't allow named parameter as select output (insert input)
----------------------------------------------------------------------------------------
Key: HHH-2692
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2692
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.4.sp1
Environment: Hibernate 3.2.4.sp1 with Annotations 3.3.0 And Validator 3.0.0
MySQL 5.0.42
Reporter: John Aylward
receive exception:
org.hibernate.QueryException: number of select types did not match those for insert [INSERT INTO ProviderInvoiceLineItem (amount,billingAccount,circuit,description,invoice,type) SELECT pili.amount, pili.billingAccount, pili.circuit, pili.description, :newInvoice, pili.type FROM com.cicat.bedrock.billing.model.ProviderInvoiceLineItem pili WHERE pili.invoice = :oldInvoice]
Idea is to copy all line items from one invoice to another. In other words, only difference between data should be the invoice. easiest way to do this is with "insert into" command and passing parameter of changed value.
* Trying to cast named parameter (:newInvoice) caused parsing error
* Trying to replace invoice with invoice_id and repacing :newInvoice with actual invoice id resulted in a "property 'invoice_id' not found" exception
Should be able to set a value through a named parameter
--
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, 10 months
[Hibernate-JIRA] Created: (HV-435) org.hibernate.validator.constraints.impl.PatternValidator rejecting empty strings
by Stephen Hiley (JIRA)
org.hibernate.validator.constraints.impl.PatternValidator rejecting empty strings
---------------------------------------------------------------------------------
Key: HV-435
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-435
Project: Hibernate Validator
Issue Type: Bug
Components: validators
Affects Versions: 4.1.0.Final
Environment: Hibernate Core 3.5.6 with MySql database (not relevant to this bug)
Reporter: Stephen Hiley
The PatternValidator currently checks for a null value and returns true from isValid() in that case. An empty string should have the same effect. This is necessary for the same reason: to allow for an empty form submission (which commonly are submitted as empty strings rather than nulls) and only validate when some value is submitted. IMO, this should be standard behavior. If nothing else, provide an option to treat empty strings as ignored in the same manner that null values are treated today.
Suggested modification:
public boolean isValid(String value, ConstraintValidatorContext constraintValidatorContext) {
if ( value == null || value.length() == 0) {
return true;
}
Thanks,
Stephen Hiley
--
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, 10 months